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APPENDIX D. LINK ERROR MESSAGES 


ABOUT THIS BOOK 


This book describes how to use the GRiD Compass as a program development tool. 
To assist you in program development, a powerful and easy-to-use development 
tool -- GRiDDevelop -- is available. GRiDDevelop provides a flexible 
development environment where you can quickly edit your source files, compile 
and link your programs, and then proceed to the debugging, re-editing cycle. 


Four programming languages are currently provided: Pascal~84, PL/M-864, 
FORTRAN-86, C and Assembler-Bé4, 


You create program source files using the text editor program, GRiDWrite. The 
Source files (along with any required INCLUDE files) are then compiled using 
the appropriate Intel compiler (Pascal, Fortran, PLM, C, ASM). Guidelines for 
using the languages and their compilers are Provided in Chapter 3 of this 
Manual. The INCLUDE files are also listed and briefly described in Chapter 3. 


The compilers produce list files and relocatable object modules. These 
modules, along with other modules you may have compiled and library modules, 
are then linked together using the Link program described in Chapter 4, 
Programs can be debugged on the GRiD Compass with the GRID debug program 
described in Chapter 5, 


A number of useful system utility programs are also available to ease system 
maintenance tasks accompanying the program development sequence. These 
Programs are described in Appendix C. 


CHAPTER 1. THE PROGRAM DEVELOPMENT CYCLE 


The GRID Compass gives you great flexibility i1 defining how you use 
the computer and its software when ceveloping programs. The 
GRiDDevelop program is a powerful and easy-to-use tool that helos 
you organize your files and greatly speed up the development 
Process. GRibDevelop is described in detail in Chapter 2. Before 
discussing GRidDevelop, however, let's take an overview of typical 
development sequences and the available tools to assist program 
development. 


The Development Sequence 
Figure 1-1! illustrates the general sequence followed when developing 


programs and also shows some of the software toals that are 
provided. 
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Figure 1-1, The Program Development Sequence 
The development process consists of four iterative phases: 
o Editing (writing) program source files with GRiDWrite 


o Compiling source files with one of the language (Pascal, PLM, 
Fortran, Assembler) compilers ey) 


o Linking compiled object modules with the Link program to produce 
modules which can be executed (run) 


o Testing and debugging the executable modules. 


This four-step sequence is repeated while you refine and debug your 
program, 


When you are creating the text source file for a program, GRiDWrite 
speeds the process with such features as automatic indentation and 
fast substitution and duplication of phrases and whole sections of 
code. For a complete description of GRiDWrite, refer to the 
GRiDWrite section in the GRiD Management Tools Reference manual. 


After you have finished writing or correcting a source program, you 
must invoke tha compiler to translate your text file into an object 
file. 


Invoking the linker program requires a more complicated sequence 
since it usually involves naming a number of files that are to be 
linked together. For example, here is a typical linker invocation: 


LINK Shell.Pas*Obj*, FormsInit.Plm*Obj*, 
‘w'Libs DataForms.Pas*Obj*, ‘w'Libs‘largeException.Asm*Obj™, @ 
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PO('w'libs'SvstemCalls*Pub*) TO Shell*Run™ BIND PURGE FASTLOAD 
ss(stack(+1000)) 


Typically, you might edit several modules, then compile them one 
after the other, and finally link the modules together along with 
various libraries. You would then test and debug the linked, 
erecutable module. If errors are discovered, you would repeat the 
edit/compile/link sequence. The goal of the program development 
environment is to make this repetitive sequence as easy and fast as 
possible. 


THE DEVELOPMENT ENVIRONMENT -- GRiDDevelop 


The GRiDDevelop program (described in Chapter 2) provides a 
development environment based on the assumption that most software 
development consists of edit/compile/link/test cycles. You can 
define many of the characteristics of the environment by filling out 
a data file with information about source file names, link command ,/ 
tines, subjects for sources, listings, and objects, and other 
miscellaneous commands, The GRiDDevelop program reads this file for 
the data to drive the program development cycle. 


You use GRiDDevelop data files to specify the files that the 
GRiDDevelop program will operate on to initiate various development 
activities such as editing, compiling, linking, and so on. 


When you use GRiDDevelop to provide the develapment environment, 
GRiDWrite is automatically invoked so you can create, edit and 
correct your source programs. GRiDDevelop also automatically 
invokes the appropriate compiler required for your source programs 
and also lets you set any controls that you want to use during the 
compilation. 


Link statement files are set up in the GRiDDevlop data file so that 
you can issue a complicated link statement with a single keystroke. 
You can also easily edit the link statement({s) during the 
development cycle directly from GRiDDevelop. 


You have several other alternatives when deciding on the environment 
you want to use when developing programs using the GRiD Compass. 
Although we suggest that you use the GRiDDevelop program, since it 
provides the fastest and most flexible environment, we describe some 
alternate approaches in Appendix A. 


CONVENTIONS FOR ORGANIZING AND NAMING FILES 


Although there are few hard ane fast rules tor organizing your 
directories and naming files, there are some conventions that have 
been adopted internally at GRiD and which are assumed by the 
GRibDevelon program. Even if you do not use GRiDDevelop, observing 
these conventions will be of value to anyone doing program 
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development work using the GRiD Compass. 


Figure 1-2 illustrates part of a typical directory on a hard disk 
device. 


Hard Disk 


Figure 1-2. Organization of Typical Directory 


The purpose of this organizational style is to keep all files that 
are logically related in the same directory. This keeps the nuaber 
of titles within each directory from getting too large. This 
organization also simplifies such maintenance activites as backing 
up files and obtaining new copies of tiles, and standardizes 
references your programs make to include files and libraries. The 
directory organization shown in Figure i-2 puts all the include 
files under one subject (Incs), all library files under one subject 
(Libs), all object files under the Objs subject, all source files 
related to a particular programs under MyPrograms, and so on. 


FILE NAMING CONVENTIONS 


There are two file naming considerations: the file title and the 
file kind (or type). 


File Titles 


GRiD-OS imposes two small limitations on file names. First, 
characters used in the title can be any of the printable ASCII 
characters between ‘space’ (ASCII code 20 hex) and DEL (ASCII code 
7E Hex) except for the single backquote (*) and tilde (™) 
characters. Second, the file name cannot exceed 253 characters 
total including device, subject, title, kind, and the delimiter 
characters. 


The Intel compilers, however, place greater restrictions on file 
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Names. They require that file names (including device, subject, 
title, kind, and the delimiter characters) be no longer than 45 
characters, You should therefore ensure that your program names do 
not exceed this limit. 


GRiDDevelop makes some assumptions about file names. (Note: Even if 
you do not use GRiDPevelop, it is recommended that you observe these 
conventions.) The first assumption GKiDDevelop makes is that you 
append some language identification information to all source fale 
titles. For example a Pascal source file should have the name 
MyProgram.Pas*Text*, a PL/M version of this program would be named 
KyProgram.Plm*Text™, an assembly language version would be 
MyProgram.Asm, and a FORTRAN version would be MyProgram.Ftn*Text™. 
This convention lets GRiDDevelop automatically invoke the 
appropriate compiler for your source programs. It also makes it 
easier to organize your files and identify the file you want even if 
do not use GRiDDevelop. 


The other convention is to identify the include files (for any 
language) by appending .Inc to the name. For example, 
MyProgram. Inc*Text™. 


File Kinds 


GRiD-OS and some GRiD applications require that files be of a 
certain "kind" in order to perform some activities. For example, if 
a file is an executable program, the system requires that its kind 
be “Run”; otherwise, the file cannot be executed. The file kind 
suffix also provides additional information about the contents of 
the file so that you can tell quite a bit about a file just by 
looking at its kind. 


When you are running application programs under GRiD-DS with the 
Executive program, you can select a data file, and the system 
automatically invokes the executable program to work or operate on 
that data file. The program that will be implicitly invoked to do 
the work must be of kind “Run fileKind*, where "fileKind" matches 
the Kind of the file being selected. For example, the program 
GRiDWRITE~Run Text™ works with a file that has a Kind of “Text”. 
The file that is to be operated on must have a kind that matches the 
fileKind of the program being implicitly invoked. For example, a 
file named Memo that you want to edit using GRiDWrite would be of 
kind “Text~. Thus, its complete name would be Memo*Text*. 


To implicitly invoke and initiate execution of the application 
Program (the program that is to do the work), just select the 
subject and title of the file you want from the File form and press 
CODE-RETURN. 


During the program development cycle, some file kinds are appended 
automatically by various utilities; others must be appended by the 
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user. Some of the file kinds you will encounter and use are listed 
below in alphabetical order. 


(NOTE: Some kinds will always appear in all caps while others are 
shown with just the first letter capitalized; Those in all caps are 
appended by Intel software such as the compilers. GRiD-OS, however, 
does not differentiate between upper and lower case: you can use 
any mix of upper and lower case in file names.) 


“Com™ @ Com (Command) file contains a list of executable 
files. You must add the “Com” kind when naming 
the file. 


“LIBS This kind is usually appended by the Lib utility 
program to identify modules that are part of the 
library, although you can specify any kind you want 
with the Lib program. 


“LST* The compilers create LST (LiST) files. Lst files 
show program listings with statement and line 
numbers, error messages, and other programming 
information. The compiler automatically adds the 
LST“ kind. 


“NPL” An MPi file is the linker’s Map file. The Link 
program automatically appends the “MP1 kind. 


~OBd* The compilers generate unlinked OBJ (Object) files oO 
and append the *OBU* kind. 


~Run™ Run files are executable files that are created by 
the Link program. Note, however, that you aust 
specify the ~Run™ kind yourself to the output file 
title in the link statement. 


*Text™ Any file created with GRiDWrite will have the kind 
“Text” appended to it unless you explicity specify 
that it be of a different kind (such as “Com™). 
Thus, the source text for a program that you create 
using the text editor will usually have “Text” 
appended ta its title. 
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THE GRIDDEVELOP PROGRAM 


The GRiDDevelop program provides a development environment based on the 
assumption that most software development consists of 
Edit/Compile/Link/Test/Debug cycles. You can define aany of the 
characteristics of the environment by filling out a data file with information 
about source file names, link command lines, subjects for sources, listings, 
and objects, and other miscellaneous commands. The GRiDDevelop program reads 
this file for the data to drive the program development cycle. 


The GRiDDevelop program resides in memory at all times. In order to use it, 
you must have the compilers (that you use), GRiDWrite, and SRiDPrint in the 
programs subject. 


THE GRIDDEVELOP MAIN MENU 


The GRiDDevelop program is invoked by filling out the File fora < 
specifying a file with a kind of Develop. The program then displays 
the main GRiDDevelop menu shown in Figure 2-1. To initiate one of 
the activites listed on the menu, just select and confirm. The 
BRiDDevelop Main menu is the default menu; once you have invoked the 
GRiDDevelop program, this menu will be displayed whenever you press 
Esc. 
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Compile and link 
Test 

Debus 

Add entry to log file 


Wevelop Select item and confirm 


Figure 2-1, The Main GRiDDevelop Menu 


The files that are to be acted on by of each of these menu items are 
specified in the GRiDDevelop data file. For example, selecting 

"Edit source file" brings up a menu displaying the filenames you 

have specified in the data file. Figure 2-2 shows an example of a 
list of source files. Confirming one of these files invokes 

GRiDWrite and brings in the file you have selected so that you can 

edit the source program. 
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Edit soure S ct item and confirm 


Figure 2-2. The Edit Source File Menu 


All of the items listed on the Main menu in Figure 2-1 will be 
described as we proceed through this chapter. Since a description 
of the GRiDDevelop data file provides an understanding of how the 
Main menu works, we will discuss items on the Main menu in 
conjunction with the data file. 


GRIDDEVELOP DATA FILES 


You use GRiDDevelop data files to specify the files that will be 
used during the various development activities such as editing, 
compiling, linking, debugging, and so on. The data file consists 
of tokens, filenames, and command lines. 


THE GRIDDDEVELOP PRE-DEFINED TOKENS 


A BRiDDevelop token is defined as all characters enclosed within a 
pair of colons. There are pre-defined tokens and user-defined 
tokens. User-defined tokens are any tokens not pre-defined by 
GRiDDevelop. Examples of user-defined tokens will be described 
after we've discussed the pre-defined tokens listed below. 
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1Controls: 

sDebug: 

Debug debugNames: 
rEnters 

1Exits 

tLinks 

iLink linkNames 
sListingss 

tLog File: 

tNamer 

:Objects: 

tPrefixs 

iPrint To: 
rSourcest 

Sources groupName: 
iTest: 

sTest testNames: 


sControls controlNames 
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Each development data file can specify as many of these tokens as 
needed to set up controls that will be presented as choices on the 
"Compile form’. The token is followed by a list of the controls 
that are to be used when the compiler is invoked. For exampie, the 
following token 


sControls Yes with Debug: DEBUG NGPRINT 


would cause the following form to be displayed when you 
select Compile froma the Main senu: 
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16-Jan-54 


Compile source files: Fill in farm and confirn 


You can then specify which files are to be compiled and 
which are to be compiled with the DEBUG NOPRINT controls 
applied, 


aDebugs 


Each development data file can specify one Debug token. 
Following this token, you can specify any number of 
command lines each of which must be ended with CR/LF, 
Typically, one of these command lines would be an 
invocation of the debuger along with your program. The 
following is an example of the use of the Debug token: 


sDebug: 
Debug MyProgram*Run™ TestFile*Text~* 


Naw, when you select the Debug item from the Main menu, 
the Debug program is invoked to operate on the 
NyProgram*Run™~ file which uses TestFile*Text*. After this 
sequence has been completed, you would automatically be 
returned to the Main menu. 


sDebug debugNames 
If more than one debug command file is needed, then 
multiple debug tokens can be defined in a Development 


file. The character string (debugName) is displayed on 
the Debug menu and the user selects which of the command 
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sequences is to be performed as part of the debugging 
sequence. You can specify as many of these tokens as 
required in each development data file. The following 
example illustrates the use of the Debug debugName token: 


tDebug Use test data file #1: 
Debug MyProgram*Run™ TestFile#i*Text* 


:Debug Use test data file #2: 
Debug MyProgram*Run™ TestFile#2*Text” 


Now, when you select Debug from the Main menu, the 
fallowing Debug menu would be displayed. 


UVebug 


You can then select the debug command file you want from 
this menu and the debugger wid! be invoked along with your 
program and the desired test data file. 


tEnters 


Each development data file can specify one Enter token. 
The token is #cllawed by a command or series of coamands 
that are to be executed the first time the development 
data file is brought into memory. For example, the 
following token 


sEnter: 
Activate ‘w'programs' Modem™Device™ 


causes the modem to be activated when this development 
data file is first brought into memory. 
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sEmites 


Each development data file can specify one Exit token. 
The token is followed by a command or series of commands 
that are to be executed when you exit the GRiDDevelop 
program. For example, the following token 


rExit: 
Deactivate ‘w' programs‘ modea*device™ 


causes the modem to be deactivated when you exit the 
GRiDDevelop program. 


sLinks 


€ach development data file can specify one Link token, 
Following this token, you can specify any number of 
command lines, each terminated with a CR/LF. Typically, 
this would include a command line invoking the linker 
program and naming the files that are to be linked and the 
resultant output file. The entire link statement is one 
command line and must be terminated with a CR/LF. The 
following is an example of the use of the Link tokens 


sLink: 

Link ‘w'Dbjs*epMain.Pas*Obj~, 
“w'Objs’epFolders.Pas“Dbj~, 
‘w'Objs'epUtility.Pas*Obj™, 
‘w'Objs'epFormsInit.Plm*0bj*, ExecPac*Font™, 

“w'libs CompactException.Asm™0bi~, 
‘w'Libs'CompactSystemCalls*Lib* TO ExecPac’Run™ BIND 
NOPURBE NOFASTLOAD PC(PURGE) ss(stack(2000)) 
PRINT(*w'Lsts‘ExecPac*MP!™) 


sLink linkNames 


If more than one link file is needed (for example, when 
linking overlays), then multiple links can be defined in a 
Developaent file. The parameter linkName is displayed on 
the Link form and you select which link command statement 
is to be performed. You can specify as many of these 
tokens as required in each development data file. The 
following example illustrates the use of the Link linkName 
token: 


tLink Roots 

LINK SampleRoot.Pas*Obj*, ‘w'Libs'pBérn0*lib™, 
‘wiLibs pBérnt™lib*, ‘w'Libs’p8érn2™1ib™, 
‘wiLibs pBérn3~lib™, ‘w°Libs'G0B7*Lib*, 
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‘w Libs LargeSystemCalls*Lib*, ‘w'Libs'DqLarge*Lnk~ 
TO SampleRoot™Lnak* OVERLAY (ROOT) NOPRINT 


rLink Overlayl: =a 


LINK SampleOverlayl.Pas*Obj~, ‘w'Libs'p@érn0™lib™, 
‘wLibs pBérnivlib*, ‘w'Libs*p@érn2*lib”, 
‘w'Libs'pBérn3“Llib™, ‘w Libs 8Qe7~Lib~ TO 
SampleOverlay1*%ink™ OVERLAY (SampleOverlay!) NOPRINT 


sLink Overlay2: 

LINK SampleOverlay2.Pas*Obj~, ‘w'Libs'p8érn0™lib*, 
“w'Libs'pBérni*lib*, ‘w'Libs'pBérn2™lib™, 
‘w'Libs'pBérn3*lib*, ‘w'Libs*80B7*Lib* TO 
SampleQverlay2™iLnk™ OVERLAY{SampleDverlay2) NOPRINT 


sLink Run Sample: 

LINK SampleRoot*Lnk*, SampleQverlayi*Lnk™, 
SampleOverlay2*Lnk* TO SampleRoot*Run* BIND 
SS(STACK(+1500)) PC (PURGE) 


Now, when you select the Link item on the Main menu, the 
following Link form will be displayed: 


Root. 
Qverlayt 
Qverlay2 
Run Sample 


Link Fill in form and confiri 


You can then select which link command file(s) you want to 
be executed from this form. 


zsListingse 
You can specify one of these tokens in each development 
data file. The string you specify (for example, 


‘device'subject*) is automatically prepended to the 
filenames that you have specified with the :Sources: token 


Q 
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slog 


when those source files are compiled. The ‘LST™ extension 
is automatically appended to the resultant files by the 
compiler. Here is an example of using the :Listings: 
token: 


Listings: ‘w'Lsts* 


Then, if you compiled source files (fileName! - fileName4) 
this would produce list files having pathnames as follows: 


“w'Lsts'fileNamel*LST* 
‘wikists'fileName2™LST* 
“wiLsts’ fileName3*LST™ 
“w'Lsts* fileName4*LST~ 


Files 


You can specify one of these tokens in each development 
data file. The pathname that you specify following the 
token can be of kind Database or Text and the file can be 
used to record or log your activities as you write, debug 
and make changes to programs. I¢ you specify a log file 
of kind Database, the GRiDFile program will be invoked by 
GRiDDevelop to dislay the contents of the log file. If 
you specify a kind of Text, GRiDWrite will be used to 
display the file. If you do not specify a kind along with 
the log file token, it is assumed that the file is a 
database and GRiDFile is used. NOTE: this assumes, of 
course, that you have the GRiDFile program in your system. 


To make entries into the specified log file, select the 


“Add entry to log file" item from the main GRiDDevelap 
menu. The following form is then displayed: 
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2e- Jaret @ 


Number J 
Version 

Hodule 

Comment. 


Log file entry: Fill in form and confirm 


The form provides four different fields that you can fill 
put to keep track of programming activities. The 
information you put into each of the fields is entirely up 
to the you but the form was designed with the following 


uses in mind. ie) 


The first field, “Number", can be used to record such 
things as error report or enhancement request tracking 
numbers. The "Version" field can be used to record the 
version number of the program module{s) currently being 
worked on. The “Module” field can record the name of the 
Program module(s) being modified and the "Comment" field 
can be filled out to describe the kinds of changes being 
made to the module(s). 


When you have completed the form with the information you 
want recorded, press CODE-RETURN to log the entry. As 
each entry is made in the log file, GRiDDevelop 
automatically appends the current date and time into the 
log file as a prefix to each entry. 


The Log file entry form is cleared as you confirm each 
entry to indicate that the entry has been recorded. A 
blank form is then displayed to allow additional entries. 
To return to the Main menu after logging entries, press 
Esc. 


To examine the contents of a log file, press CODE-T ta 


display the Transfer menu and then select the “Examine log 
file” item. If the log file was specified with a kind of 


O 
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Database, GRIDFile wili automatically be invoked and yau 
can use the Find command (CODE-F! of GRiDFile to display 

QO the contents of the file. If the log file is of kind 
Text, GRiOWrite 1s invoked and the contents cf the file 
wijl be displayed automatically. 


sNames 


You can specify one of these tokens in each development 
data file. The string you specify is automatically 
displayed as the leading phrase in the message line of the 
main GRibDevelop menu. For example, if you specify the 
following with this token 


rName: Sample Development 


the screen displayed by GRiDDevelop would be as shown in 
Figure 2-3, 


156 pm 


Edit list file 


Tompi te 

Link 

Compile and Lirik 
Test 

Rebus 

Add entry to low file 


Sample Development t item and canfirm 


Figure 2-3, Using the Name Token 


Objects 


You can specify one of these tokens in each development 
data file. The string you specify (for example, 
‘device’subject') is automatically prepended to the 
filenames that you have specified with the :Sources: token 
when those source files are compiled. The ‘Obj* extension 
is automatically appended to the resultant files by the 
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compiler. Here is an example of using the :Objects: 
token: O 


sObjects: ‘w'Objs* 


This would cause the object files produced by compilers to 
have pathnames as follows: 


‘w'Objs*fileNasel*Obj* 

‘w'Objs’fileName2*Obj* 

‘wObjs* fileName3”Ob 5” 

*w'Qbjs' #ileName4~Ob j~ 
{and so on) 


aPrefixa 


You can specify one of these tokens in each development 
data file. The string you specify is the Device-Subject 
name or simply the Subject name where source files reside. 
This lets you define source file names in the data file by 
just specifying the Titles the prefix you specify will 
automatically be prepended to the Title. After each 
command, the prefix is reset to the Subject specified with 
this token. Here are two examples of using the :Prefix: 
token 


iPrefix: ‘w''1/0 Driver’ oO 


Prefix: MyPrograas 


sPrint Toe 


You can specify one of these tokens in each development 
data file. The string you specify is prepended to the 
destination filename before printing. It is useful for 
printing to GRiDServer. Here is an example of the :Print 
To: token 


Print Tos ‘‘Nexus.1:Printer Queue’ EpsonMXB2°’ 


sSources: 


You can specify one of these tokens in each development 

data file. Following the token, you provide a list of 

source filenames. Filenames must be one per line and can 
include spaces. Leading spaces are stripped unless 

quoted. Each filename title must end with a suffix 

indicating the compiler to invoked for that source file. @ 
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sSour 


The following title suffixes are recognized by 
GFiDDevelop: 


»pas (Pascal) 
opim (PL/M) 

-asa (Assembler) 
-ftn (FORTRAN) 


Here is an example of the :Sources: token 


:Sources: 
ModelPriv.ine 
ModelText.inc 
FormsInit.pla 
Unparse.pas 
"Teast Model.pas’ 


Note that if the file name title ends with a suffix other 
than one of the four recognized by GRiDDevelop, no 
compiler will be invoked. This lets you have “include” 
files (.Inc) be listed with your source files so that you 
can easily edit them using the "Edit source file” command 
from the Main menu of GRiDDevelap. 


ces groupName: 


if you have programs that have many source files, this 
token lets you categorize a collection of source files as 
a “group”. Then, using the "Change source groups” item on 
the GRiDDevelop Main menu, you can specify which group(s) 
of files are to be displayed for editing, compiling, and 
so on. You can specify as many of these tokens as required 
in each development data file. The following example 
illustrates the use of the :Sources groupName: token 


Sources Group 1: 
Filel.Pas 
File2.Plm 
Files.Asm 


Sources Group 2: 
File4.Pas 
FileS.Plm 
Fileé.Asm 


Sources Group 3: 
File?.Pas 
File®.Plm 
File?, Asm 
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Now, if you select “Change source groups" from the Main 
menu, the form shown in Figure 2-4 15 displayed: 


Sr He 3 12:16 am © 


Group 1 
Group 2 
Group 


Source 3roups: Fill im form and confirm 


Figure 2-4, The Change Source Groups Form 


With all three groups set to "Yes" on this form, you would 
get a display similar to the screen shown in Figure 2-5 if 


you select "Compile* or “Edit source file” from the Main 
menu. @ 


Yes Yer with Debug 


Filel Pas 
File2.Pas 
File? Pas 
Filed Ftn 
FileS Fir 
Files .Ftn 
File?.PLM 
Files.PLM 
Filed ASM 


Lompile source files: Fill in form and confirm 


Figure 2-5. The Compile Form with All Groups Enabled 
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I4 you enable only groups ! and 3 via the Change Source 
Groups farm, the Compile form would be as shown in Figure 
2-6, 


Yes ‘fes with Getus 


Filel.Fas 
File2.Pas 
Filed Pas 
File?.PLM 
Fil PLM 
Filed. ASM 


Compile source files: Fill in-form and confirm 


Figure 2-6. The Compile Form with Groups ! and 3 Enabled 


eTests 


Each GRiDDavelop data file can specify one Test token. 
Following this token, you can specify any number of 
rommend lines each of which must be ended with CR/LF. The 
following is an example of the use of the Test token: 


rTest: 
GRiDPlan SampleData 


Now, when you select Test from the Main menu, GRiDPlan 
would be invoked along with the file SampleData. 


rTest testNamer 


If more than one test command is needed, then multiple 
test tokens can be defined in a Development file. The 
Parameter testName is displayed on the Test form and the 
user selects which of the test sequences is to be used. 
You can specify as many of these tokens as required in 
each development data file. The following example 
illustrates the use of the :Test testName: token 


iTest GRiDPlan: 
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GRiDPlan SampleData 


rTest GRIDPlot; ) 


GRiDPlot PlotTestData 


Now, when you select Test from the Main menu, the Test 
menu shown below will be displayed: 


16-Hou-83 


t item and confirm 


O 


You can then initiate the desired sequence by selecting it 
from the Test menu. 


USER-DEFINED TOKENS 
You can define your own tokens which can have any number 
af command lines associated with them. The tokens you 
define are placed as items on the GRidDevelop commands 
menu. For example, if you have the following tokens in a 


development data file, 


:Command Line Interpreters 
DevelopmentExecutive 


:GRiDManager: 
‘GRiDManager’ 


the Commands menu displayed when you press CODE-? would be 
as shown in Figure 2-7, 


O 
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Options 
Guit 
Transfer Code-T Exchange, print files 


Usage 
Cancel 


TOManager 
Chanse source groups 

Ese Return to main menu 

Code-O = Set development characteristics 

Code-@ Exit 


Code-U = Show memory usage 
Code-ESC Exit 


Figure 2-7. The Commands Menu with User-Defined Tokens 


Now, you can invoke the Development Executive program by 
selecting "Command Line Interpreter", or invoke 
GRiDManager by selecting it from the menu, 


Command Modifier Characters 


GRibDevelop recognizes two characters that can modify the 
execution of command sequences that follow such tokens as 
Debug, Link and Enter. 


If the first character in a coamand line is a question 
mark {?), then after the command is executed the system 
will pause and not proceed until you press a key on the 
keyboard, 


If the first character in a command line is a semicolon 
(3), then the command that follows the semicolon is simply 
ignored. 


THE GRiDDEVELGP COMMANDS MENU 


The Commands menu appears when you press CODE-? and 
displays the items shown in Figure 2-7. (Remember, the 
first two items in this figure are the user-defined tokens 
we used as an example.) The items on the Commands menu 
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are generally self-explanatory and should be familiar to 

you from other GRID applications. The Options (CDDE-O) 

and Transfer (CODE-1T) commands, however, deserve some SS) 
additional discussion, 


THE OPTIONS COMMAND 


The Options command currently lets you specify only one 
option: whether to halt on errors. If you issue this 
command by selecting it from the Commands menu or by 
pressing CODE-T, the form show below is displayed: 


18-Jan-34 


Halt on errors [& i 


=: Fill in form and contin 


If you specify "Yes" on this form, an error encountered 
while compiling will return you to the GRiDDevelop main 
menu after the module that produced the error has been 
compiled. This prevents compilation of subsequent modules 
that you may have specified via the Compile form. Only 
compile errors will cause a halt; compiler warnings do not 
prevent continuation. 


If you specify "No” on this form, errors encountered 
during compilations are ignored and compilation of any 
other selected modules will proceed. Note that if you 
have selected files to be both compiled and then linked, 
the linkage will not be performed if any compile errors 
are encountered regardless of the setting of the Options 
form, 
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THE TRANSFER MENU 


Figure 2-& shows the items on the GRibDevelop Transfer 
menu which appears when you select the Transfer item from 
the Commands menu or when you press CODE-7. 


Examine log Pile 

Erase a file 

Show characteristics of a file 
Edit anu File 

Print any file 

Print list filecs) 

Print source filets) 


Transfer: t item and confiri 


Figure 2-8. The GRiDDevelop Transfer Menu 


The second, fourth, and fifth items on this menu 
("Exchange for another file", "Erase a file", and "Show 
characteristics of a file") operate just as they do in 
other GRID applications. They simply bring up a File form 
that you fill out specifying the file(s) to be acted on. 
The "Edit any file" and “Print any file" items also bring 
up the standard File form te let you select files for 
editing with GRiDWrite or printing. The first item 
("Change this development file") and the last two items 
(’Print bist file(s)" and "Print source file(s)” operate 
somewhat differently than in standard GRiD applications 
and are described in the paragraphs that follow, 


Changing the Development Data File 


The first item on the Transfer menu, "Change this 
development file", lets you edit the contents of the 
development data file currently being used to drive the 
activities of GRiDDevelop. When you select this item, 
GRiDWrite is automatically invoked and the current 
development data is brought into memory. You can then 
edit the deta to meet the changing characteristics of the 
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development process. When you quit from this editing 
activity, you are returned to GRiDDevelop with the new 
contents cf the data file now driving GRiDDevelop. =) 


Printing List and Source Files 


The last two items on the Transfer menu, "Print list 
file(s)" and “Print source file(s)", let you select one or 
more of your list/source files for printing. For example, 
if you select “Print source file{s)" from the Transfer 
menu, the form shown in Figure 2-9 is displayed. 


Yas 


Filei Pas 
Filez.Pas 
File3.Pas 
Filed. Ftn 
FileS.Ftn 
Fileé.Ftn  ) 
File?.PLM 
File’. PLM 
File?.AsH 


Print source filets): Fill in form and contirn 
Figure 2-9. The Print Source File(s} Form 


This form displays all of source files in the currently 
enabled groups -- see the :Sources groupName: token -- and 
lets you indicate which files or files are to be printed. 
When you confirm this form, the indicated files will be 
printed. For example, confirming the fora shown in Figure 
2-10 will cause source File2, FileS and File 9 to be 
printad. 
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Senet ESS pa 


Filel. 
Filez. 
File3. 
Filed. 
Files. 
Files. 
File?. 


Files 
Filed 


Frint source filets) Fill in form and confirm 


Figure 2~10. Printing Selected Source Files 


The “Print list file(s)" form works in exactly the same 
way as illustrated for "Print source filefs)". 


The list or source files specified will be printed at your 


attached printer unless you have used the :Frint To: token 
to redirect the output to a file. 
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CHAPTER 3. COMPILERS, LIBRARIES, AND INCLUDE FILES 


This chapter describes the compilation procedures to follow to obtain an 
object file from a program’s source file, and discusses the include files that 
you may need for your programs and library tiles that are available during 
Vinking. 


COMPILING PROGRAMS 


The compilers for Pascal-B6, PL/M-86, FORTRAN-86 and Assembler-86 
are described in the foliowing Intel Language reference manuals: 


PASCAL-86 User‘s Guide 
FORTRAN-86 User’s Guide 
PL/M-84 User's Guide 
Assembler-84 User’s Guide 


The descriptions of the compilers in these manuals are comprehensive 
but there are several considerations to observe when using them on 
the GRiD Compass system, These special considerations are discussed 
in the paragraphs that follow. 


Compiler Size Controls 


Most of the compilers provide size controls - LARGE, COMPACT, 
MEDIUM, SMALL. You must use either the compiler’s COMPACT or LARGE 
control. If either a program or a block of data used with the 
program are larger than 44K, you must use the LARGE control; 
otherwise use the COMPACT control since this will result in smaller 
programs, 


Since LARGE is the default for the Pascal-86 compiler, you must 


specifically specify COMPACT if that is what you desire. The 
default for the PL/M-86 compiler is SMALL; therefore you must 
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LIBARIES 


Pascal-B6 


explicity specify either the COMPACT or LARGE control when compiling 
PL/M programs. With FORTRAN-86, the only chaice is the LARGE case: 
therefore, FORTRAN programs must be compiled with this control, 


When you purchase a language, each of the compilers is provided on a 
diskette under the subject "Programs". Other files associated with 
each language are provided on the same diskette as the compiler and 
are listed in the paragraphs that follow. 


NOTE: the language diskettes also contain language specific include 
files under the subject Incs. These files will be discussed at the 
and of this chapter. 


Libraries and Modules 
The file named Pascal*Run® is under the Programs subject and 


contains the Pascal-86 compiler. The remaining files are under the 
Libs subject and contain the run-time support libraries and modules. 


pascal™Run* -- the compiler 

pBérno™Lib”™ 

pBorni™Lib” Libraries that must be linked with 
p8arn2*cib™ the Pascal object module if you 
pBarn3*Lib™ use any of the Pascal I/O calis, 
rtnull*Lib” 

DqLarge*Lnk* 


If you use the input/output routines provided by GRiD-OS and the 
Common Code, then you should not use the Pascal 1/0 procedures READ, 
READLN, WRITE, and WRITELN, and you need not link in the Pascal run 
time libraries listed above. Instead, you need only link in the 
GRiD-supplied library file “LargeSysteafails*Libs”" or 
“CompactSystemCalls*Libs” (depending on whether you are using the 
LARGE or COMPACT size control when compiling). 


NOTE: Tf you do not link in the Pascal runtime libraries then you 
must not make any calls to Pascal [/0 statements. Also, the PROGRAM 
declaration at the beginning of a Fascal program, do not specify the 
nodule as "Input, Output" nor any other file names or you will get 
link errors. 


FORTRAN-86 Libraries and Modules 


The file named Fortran*Run* is under the “Programs” subject and 
contains the FORTRAN-@6 compiler. The remaining files are under the 
Libs subject and contain the run-time support libraries and modules. 
Unlike Pascal, when using Fortran you must always link in all of the 
Fortran run-time libraries listed below. 
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O 


© 


fortran™Run™ -- Fortran compiler 


fBérno™Lib™ 
+B4rn1™lLib™ 
#9rn2*Lib~ Run-time Libraries 
484rn5~Lib~ 
#Oarn4~Lib™ 
DqLarge”Lnk”® 


PL/M-86 Libraries and Modules 


The ¢ile named plm*Run™ is under the Programs subject and contains 
the PL/M-Bé compiler. The other file contains the run-time support 
libraries and is under the subject Libs. 


plm*Run® 
plm*Lib”™ 
DqLarge™Lnk~ 


8087 Libraries and Modules 


These files contain the run time support libraries and modules 
reguired by the 8087 Numeric Data Processor and aust be included if 
the program being compiled uses the 8087. To determine if your 
program uses the 8087, refer to the appropriate Intel language 
manual. If you are not certain, then go ahead and link in these 
libraries. The only penalty is a slightly longer time needed to 
link. 


BOB7*Lib* 
87null*Lio® 
cel87™Lib™ 
dconB7*Lib 
ehB7*Lib™ 


INVOKING THE COMPILERS 


The compilers can be invoked automatically from GRiDDevelop if you 
append the appropriate language identification suffix to the source 
file name (.Pas, .Pim, .Ftn. .Asm). (See Chapter 2 for details.) 
GRiDDevelop also lets you specify any compiler controls you require 
via the GRiDDevelop data file described in Chapter 2. 


If you do not use GRiDDevelop, you can invoke the compilers from a 
command line (see Appendix A) by Simply entering the compiler’s 
name, for example plm or pascal, followed by the source program name 
and any compiler controls. (Refer to the appropriate Intel language 
manual for a deseription of compiler controls usage.) For example: 


pla MyProgram.Plm*Text™ LARGE DEBUG 
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pascal MyProgram.Pas*Text™ NOLIST i) 


fortran Myprogram.Ftn™Text™ XREF 


THE SYSTEM AND LANSUAGE INCLUDE FILES 


The language compilers provide an INCLUDE contro] that let you 
include other source modules for compilation with your program. 
(Refer to the appropriate Inte] language manual for a description of 
INCLUDE). The include files provided by GRiD are simply a text 
insertion mechanism: they let you use the declarations of 
GRiD-developed procedures and functions within your programs without 
having to laboriously type ail af them into your source file. 


There are several files that must be included during compilation of 
your source programs if the program makes any direct, explicit calls 
to the GRiD-OS. As you develop your awn programs you will probably 
develop your own groups of include files. 


Two sets of include files are currently provided on the language 
diskettes under the subject Incs: one for Pascal programs and one 
for PL/M programs. 


Pascal Include Files PL/M Include Files 

Common, Inc*Text” PLMLits.inc*Text” O 
OsPasTypes.inc*Text™ OsPlaTypes.inc*Text™ 
OsPasProcs,inc*Text™ OsPlaProcs.inc’Text~ 
ConPas.inc*Text™ ConPla.inc*text” 


The Common. Inc*Text™ and PLMLits.inc™text™ files contain some 
standard declarations used in the Pascal-86 and PL/M-B4 languages 
and should always be included. The OsPasTypes.inc*Text™ and 
OsPlaTypes.inc™Text™ files contain declarations of data types needed 
if explicit GRiD-OS calls are made. The OsPasProcs.inc“Text™ and 
OsPlmProcs.inc™Text™ files contain the definitions of functions and 
procedures comprising the GRiD-OS calls. The include files above 
should be included in the order in which we have listed them to 
avoid undefined symbol errors. 


Many more include files are used to define the functions and 


procedures available in Common Code. Refer to the Common Code 
Reference manual for information on other available include files. 
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O Examples of Include Control Statements 


The following examples illustrate the format of typical INCLUDE 
controls for the compilers as they would be stated within your 
“Text™ source file, 


NOTE: The dollar sign (#) must be in column { of your source file to 
be recognized by the compilers. 


Pascal-Bé Example: 


SINCLUDE (‘w'incs‘Common, Inc*Text*) 
SINCLUDE (‘w'incs*’ConPas.Inc*Text*) 
SINCLUDE ("wW'ancs'GsPasTypes. Inc™Text™) 
SINCLUDE {'w'incs’OsPasProcs.Inc*Text*) 


PL/N-86 Example: 
INCLUDE (‘w'incs'Plalits. Inc*Text~*) 
SINCLUDE (‘woincs’ConPlm. Inc*Text™) 


INCLUDE ('w'incs OsPl mTypes. Inc*Text™) 
INCLUDE ('w'incs’OsPlmProcs, Inc*Text*™) 
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CHAPTER 4. THE LINK PROBRAM 


The Link program combines relocatable object modules produced by the language 
compilers and resolves references between independently compiled modules. The 
input to the Link program is a list of files and optional controls; the output 
is a single object file and (optionally) a print file. 


The Link program is thoroughly described in the Intel manual "“iAPX 86,88 
Family Utilities User's Guide" which is supplied with development systems. 
Refer to this manual for a complete description of Link including descriptions 
of some patentially useful controls that are not covered in this chapter. 

This manual also describes the Librarian (Lib) and CREF (cross-reference 
listing generator) programs that are supplied with development systems. 


TNVOKINS THE LINK PROGRAM 
The general syntax of a link invocation is 


LINK inputList TO outputFile*Run™ BIND SS(STACK(+nnnn)) 


{contro} s} 
Where: 

inputList contains the filenames of object modules 
and libraries, 

outputFile the filename that is to receive the linked 
output module that the Link program 
produces, 

BIND is a control that must always be specified 


in the final link of a program to obtain a 
load time locatable module. 


SS(STACK (+nnnn)) is a control that must be specified to 
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obtain a sufficiently large stack Segmant 
Size (35) for program execution, @ 


centrols are the ostional cantrols (summarized in 
Table 4-1) that modify the standard 
operation of the Link program, 


Each pathname in the inputList is separated from the preceding file 
name by a comma and the last pathname in the list is separated from 
TO by a space. for example: 


LINK ‘wiMySystem'MyFilel*Obj™, ‘w'MySystem MyFile2™Obj, 
“‘w'Libs CompactSystemCalls*Lib* TO ‘w'MySystem'NewFile~Run™ 
BIND SS(STACK (+1500)) 


The pathname of the output file 1s separated from TO by a space, and 
any controls you specify are separated from each other by a space. 


LINK INVOKATION EXAMPLES 


The following example takes the Pascal object module named 
MyFile.Pas*Obj*, links it together with several of the Pascal and 
8087 library modules located under the subject ‘w'libs and produces 
a linked and bound output module named MyFile*Run™. 


LINK MyFile.Pas*Obj*, ‘w'libs’PBORNO*Lib”, ‘w libs’ PBSRNI~Lib™, 
‘wilibs PBSRN2“Lib*, ‘w'libs'PBGRNS*Lib*, ‘w'libs'CEL87*Lib™, @ 
‘wilibs EHB7”*Lib™, ‘w'libs'SOB7*Lib™, ‘w libs’ DCONB7*Lib™, 

‘w'iibs DqLarge*Lnk™ TO MyFile*Run® BIND SS(STACK(+1500)) 

PC (PURGE) 


NOTE: You can put this link invocation sequence into a GRiDDevelop 
data ¢ile and then initiate the link operation from the GRiDDevelop 
menu, See Chapter 2 for examples. If you do not use GRiDDevelop, 
you can create a command (“Com”) file and then initiate the link 

with the Do program. See Appendix A far examples of command files. 


If you do not use any Pascal input/output procedures then you need 
not link in Pascal run time libraries (PB&RNO-PGSRN3) nor the 
‘wilibs'DqLarge“Lnk™ file: Instead, simply link in the file 
‘w'Libs'CompactSystemCalls*Lib™ or ‘w'Libs*LargeSystemCalls™Lib™ to 
obtain the GRiD I/D procedures. In this case, the link invocation 
sequence would be: 


LINK MyFile.Pas’Obj*, ‘w'libs'CELB?7*Lib*, ‘w'libs*EHB7*Lib™, 
‘wlibs’8087*Lib*, ‘w'libs"DCONB7*Lib%, 
‘wlibs'CompactSystemCalls*Lib™ TO MyFile*Run™ BIND 
SS(STACK(+1509)} PC (PURGE) 
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The following example shows the link commands for a FORTRAN progran: 


LINK MyFile.Ftn*O0bj*, “w'libs*F&6RNO*Lib™, ‘w libs F@4RNI*Lib*, 
‘wlibs'’F@6RN2*Lib™, ‘w'libs’FBORNZ*Lib*, ‘w libs’ FEdRN4~Lib™, 
‘wolibs’CEL97™Lib*, ‘wilibs EHS7*Lib*, ‘w'libs' 8087™~Lib*~, 

‘w libs BCON@7*Lib*, ‘w'libs’DqLarge*Lnk™ TO MyFile*Run™ BIND 

SS(STACK (+1500)) FC(PURGE) 


LINK PROGRAM CONTROLS SUMMARY 
Table 4-1 summarizes the controls available with the Link program 
that are descrited in this chapter and showns the default setting 


for each control. 


Table 4-1, Summary of Link Controls 


Control Abbrev. Default 
ASSUMEROOT (pathName) AR ie 
BIND | NOBIND BI ot NOBI NOBIND 
FASTLOAD + NOFASTLOAD FL t NOFL NOFL 
MAP 3} NOMAP MA + NOMA MAP 
NAME NA ae 
OVERLAY | NOOVERLAY ov + NooV NOOVERLAY 
PRINT(pathName)> | NOGPRINT PR i NDOPR PRINT 
PRINTCONTROLS (PURGE) PE 
PURGE | NOPURGE PU i NOPU NOPURGE 
SEGSIZE {(STACK{+nann)? ss mie 
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ASBUMEROOT 


Syntax Abbreviation Defauit © 
ASSUMERDOT (pathName) AR == 


Definition 


ASSUMEROOT is used only in conjunction with the OVERLAY control and 
suppresses the inclusion of any library module{s) in an overlay if 
those modules have already been included in the root file identified 
by pathName. ASSUMERDOT causes the root file to he scanned, and all 
external, undefined symbols in the overlay modules which have a 
matching definition in the root file are marked "temporarily 
resolved." This marking means that while a library search for the 
symbols will not be made, their status remains externally undefined 
until the overlays are linked with the root. See Appendix B for 
examples of the use of ASSUMEROOT. 


BIND ! NOBIND 


Syntax Abbreviation Default 
BIND BI NOBIND 
NGBIND NOBI 
Definition 
BIND combines the input modules into a lead-time-locatable aodule O 


that can then be loaded and executed. Since the default for this 
control is NOBIND, you aust always explicitly specify the BIND 
control during the final link to obtain a module that can be loaded 
and executed under GRiD-OS. 
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FASTLOAD +: NOFASTLOAD 


oO 


Syntax Abbreviation Default 
FASTLOAD BL, NOFASTLOAD 
NOFASTLOAD NOFL 


Definition 


MAP 


Definition 


FASTLOAD reduces program loading time and also produces the most 
compact object file. Loading time is reduced by concatenating data 
records to a maximum length of 44K. The object file size is reduced 
by removing such information as local symbols, public records, 
comments, and type information {unless the object file contains 
unresolved external syabols). To obtain an executable object file 
of the smallest size, use the both the FASTLOAD and PURGE link 
centraols, 


The FASTLOAD controi should not be used if you are going to be 
debugging the program. 


NOMAP 
Syntax Abbreviation Default 
MAP MA MAP 
NOMAP NOMA 


MAP produces a link map and inserts it in the PRINT file (*MPI*) 
that is generated by the Link program. (The PRINT file is described 
at the end of this chapter.} The link map contains inforaation 
about the attributes of logical segments in the output module. This 
includes size, class, alignment attributes and overlay name (if the 
segment is a member of an overlay}. If you specify NOMAP, the PRINT 
file will not include a link map. 
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NAME 


Syntax Abbreviation Default 


NAME (moduleName) NA Module keeps 
current name 


Definition 


NAME assigns the specified moduleName to the output aodule’s header 
record. If you do not use the NAME control, the output module will 
have the name of the first module in the input list. Note that NAME 
does not affect the output file’s name; only the module name in the 
output module’s header record is changed. 


The moduleName may be up to 40 characters long and may be composed 
of any of the following characters in any order: question mark {?), 
commercial at (@), colon (+), period (.), underscore (_), 
A,B,C,...2, or 0,1,2,...9. Lower case letters may be used, but they 
are automatically converted to uppercase by the Link program. 


OVERLAY 1! NOOVERLAY 


Byntax Abbreviation Default 
OVERLAY { (over layName) } ov NOOVERLAY 
NOOVERLAY NgoV 


Definition 


QVERLAY specifies that al] of the input moduies shall be combined 
into a singte overlay module. If you specify the optional 
overtayName argument, ail segments contained within the overlay 
module have that name in addition to their segment names and class 
names. If no cverlayName is specified, the Link program uses the 
module name of the first module in the input list as the 
overlayName,. 


You must link each overlay in a program separately before you link 
all the overlays into a single object module. When linking root and 
overlay files, the Link program assumes that the first file in the 
invocation line is the root. When you call the operating system to 
load the overlay, you must use the same overlay name that you 
specified (overlayName) with this OVERLAY control. See Appendix B 
for a complete description of overlays. 
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PRINT ! NOPRINT 


O Byntax Abbreviation Default 
PRINT{ (pathName) } PR PRINT (objectFile*MP1™) 
NOPRINT NOPR 
Definition 


PRINT lets you specify the pathname for the PRINT file created by 
the Link program. (The PRINT file is described at the end of this 
chapter.) If the PRINT control is not specified or if the control 
is given without the pathName argument, the print file will have the 
Same pathname as the object file output by the Link program except 
the Kind extension will be “MP1* instead of “RUN*. NOPRINT prevents 
the Link program from creating any print file. 


PRINTCONTROLS (PURGE) 


Syntax Abbreviation Default 
PRINTCONTROLS (PURGE) PC(PU) = 
Definition 
©) PRINTCONTROLS (PURGE) removes all information about the debug or 


public records from the print file (MP1) produced by the Link 
Program and thus significantly reduces the size of that file. 


The Link Program 4-7 


PURGE 


Syntax Abbreviation Default © 
PURGE PU NOPURGE 
NOPURGE NOPU 

Definition 


PURGE removes all of the debug or public records from the object 
file and their information from the print file. If you specify both 
the FASTLOAD and PURGE controls, you will obtain the most compact 
output object file possible. The records that would be included by 
NOPURGE and NOFASTLOAD are useful when debugging programs, but are 
uonecessary for producing executable code. 


SEGSIZE 
Syntax Abbreviation Default 
SEGBSIZE(STACK<{+nnnn)} SS(STACK (+nnan)) => 
Definition 


SEGSIZE(STACK(+nnnn)) specifies the amount of additional memory 
space needed for the stack segment. The compilers automatically @ 
determine how much stack a program needs. If your program did not 

call any common code or GRiD-OS routines directly and has no 

re-entrant procedures, the compilers will generate the correct size 
stack. However, if you do call common code or GRiD-OS routines, 

they also use your stack and you must increase the size of the stack 
accordingly. There are no hard and fast rules for the amount of 

stack you will need. A good first approximation is +1500. If you 

have a program which crashes in unexpected ways, the first thing you 
should try is to increase the stack size further. 


NOTE: If you omit the plus sign from the size specification, it is 


treated as the absolute size of the stack segment and could cause 
failure from an insufficient stack. 
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THE LINKER‘’S PRINT FILE 


The Link program always creates a print file unless you specify 
NOPRINT. The optional pathName argument to the PRINT control 
designates the name of the print file. The default name is the name 
of the output object file but with a Find extension of *“MFL*, 


The print file may contain as many as five parts: 


A header (always present) 

A link map (unless NOMAP specified) 

& group map (always present) 

A symbol table (unless PURGE or PC(PURGE) specified) 

An error message list (always included when errors occur) 


oeco0aga 


Most of the information contained in the print file is used for 
diagnostic purposes when constructing such things as system loaders 
and will be of little or no interest to most programmers. The only 
parts of the print file that may be of general interest and use are 
the unresolved symbols list which is part of the link map and the 
error message list st the end of the print file. 


The unresolved symbol list itemizes each external symbol whose 

public definition was not encountered, The module that references 
the unresolved symbol 1s also indicated. The printed message that 
appears under the heading UNRESOLVED EXTERNAL NAMES is as follows: 


symbolName IN pathName(moduleName) 


Warning messages are listed consecutively as warning situations are 
enceuntered. They may appear before or after the link map, 


Errors always terminate processing - an error message will always be 


the last line in the print file. For a discussion of the 
interpretation of individual messages, refer to Appendix D. 
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CHAPTER Si THE DEBUGGER 


The debugger program (Debug) is a symbolic, interactive, sultitasking debugger 
for high-level languages. It lets you debug programs at the source level by 
examining a program as it executes. Debug lets you: 


© Set breakpoints in the program so you can check the progress of program 
execution at any point. You can set breakpoints at a line number, at a 
procedure beginning or end, upon return from a procedure, or at a memory 
location. 

o Display/examine the contents of variables, semory locations, and registers. 

o Change the contents of registers, memory locations, and variables. 


o Dump the contents of memory in both hexadecimal and ASCII formats, 


o Check the status of system aultitasking operations by displaying 
information concerning processes, semaphores, and nessages. 


o Alternate between two screens, one for the debuger and the one being used 
by your prograa. 


Some of the debugger commands are invoked by pressing CODE and one other key, 
while others are invoked via a comaand line. The commands are listed in Table 
5-1 and will be described in alphabetical order in the pages that follow. The 
CODE-key commands are described first and then the command line commands. 
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CODE-KEY Command 


display help info 
set Breakpoint 
Clear breakpoint 
Duplicate last text line 
invoke development Executive 
display Info, optians 
display current Location 
display tasks Messages 
set/change Options 
Proceed program execution 
Quit the debugger 
display Registers 
display Tasks, semaphores 
toggle Windows 

C ES€ape from the debugger 


OQEADOVOZCHmMoowy 


m 


Command Line Commands Syntax 


Display Address @<name> 

Display Value <nameiabsMem> 
Assign Value name >=expression> 
Dump/Change Memory <absMem>= 

Dump <len> Bytes <nametabsMem> <len> 


Table 5-1. Debugger Command Summary 


COMPILE AND LINK CONSIDERATIONS 


In order to view symbol names and line numbers, the program to be 
debugged must be compiled with the #DEBUG option specified, and the 
PURGE and FASTLOAD controls in the Link program must not be 
specified (NOPURGE and NOFASTLOAD are the defaults for these 
controls). 


INVOKING THE DEBUGGER 
The Debug program can be invoked by issuing the following command 
via the command line interpreter of the Development Executive 
program (described in Appendix Ab: 


DEBUG programName Cparameters] 


Note: You can also invoke the Debug program from GRiDDevelop. 
See Chapter 2 for details. 


The optional parameters are those that might be needed by the 
program being debugged. 
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When it is invoked, the debugger creates a set of debugging files 

Oo (22IDEBUG.MOD, ZZZ2DERUG.PUB, ZZZDEBUG.SYM, ZZZDEBUG.TYP, and 
TIZDEBUG.WIN). These are information files used by the debug 
program and require approvimately the same amount of disk space as 
the program module occupies, 


After creating these files, the debugger displays its prompt 
character, an asterisk (#). You can now issue the debugger 
Commands. 


DEBUGGER SYNTAX AND TERMINOLOGY 


The following syntax conventions and abbreviations are used 
throughout this chapter. 


decimalConstant -- a number composed of the digits 0 through 9. 


hexConstant -~ a decimal digit (9-9) followed by any combination of 
hex digits (0-9,A,B,C,D,E,F) and ending with the character "H". 
For example, OFFEBh. 


absMem -- an absolute memory address with the segment value followed 
by s colon and ending with the offset value. For example, 
OODIh:OFFEH or #AX:#IP (see register notation below). 


register -~- the number or pounds character (#) followed by the 
standard Intel symbol for 6086 registers. For example, #AX and 
#SP, 


nqumber -~ a decimal constant. hex constant, register reference, or 
an equation composed of these simple math operations (+,-,%#,/) 
and unary plus and minus, Note that equation operators are 
evaluated from left to right -- there is no operator 
precedence. 


line# -- any number that has a corresponding statement number in the 
source code, 


varName -- the name of a variable in the program being debugged. 
procName -- the name of a procedure in the program being debugged. 
module -~ the name of any module in the program being debugged. 

If the varName, procName, or line# you want to refer to is in the 
current module being debugged, you need not precede the name with 
the module name. If you want to refer to a name or line# in another 
module, explicit module references can be made by preceding a 


varName, procName, or line# with the module name and a colon {:), 
For example: 
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NEWMOD: BESTPROC ‘S) 


References to a varName or procName that is in the public domain are 
made by prefixing the name with a colon (:). For example: 


:PUBPROC 


CODE-KEY COMMANDS 


Many of the debugger commands can be initiated by simply pressing 
one of the standard keyboard keys while halding down the CODE key. 
The paragraphs that follow describe these commands in alphabetical 
order. 


THE HELP (CODE-?) COMMAND 
This command displays a brief summary of the debugger commands -~ 
both the CODE-key and command Line commands. When you press CODE-? 


you will get the following display: 


All Input Ends with Confirm 
ESC Key Aborts Any Command 


COMMAND LINE 


<name> Display Address @ 
<nameiabsMem> Display Value 
<name>=<expression> Assign Value 
<absMem>= Dump/Change Memory 
CnametabsMem> <len> Dump <len> Bytes 
CODE-KEY 

? this help info 

B set Breakpoint 

Cc Clear breakpoint 

1 display Infa, options 

M display tasks Messages 

q set/change Options 

P Proceed program execution 

Q Quit the debugger 

R display Registers 

eT; display Tasks, semaphores 

W toggle Windows 

Esc ESCape from the debugger 
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THE SET BREAKPOINT (CODE-B) COMMAND 


This command allows you to set breakpoints in your program so you 
tan monitor program execution. You can specify the breakpoints by 
line number, absolute memory address, or by procedure name, You can 
also specify that a break occur after the breakpoint has been 
reached a certain number of times. If a procedure name is used to 
specify the breakpoint, you can also specify whether the break 
should be at the beginning or end of the procedure, or upon return 
fram the named procedure. 


When you press CODE-B, the debugger prompts you with the following 
message: 


Set Breakpoint At: CpreviousBreakpointd 


If you have previously set breakpoints, the most recently 
established breakpoint will be displayed after the prompt message. 
If this is the first breakpoint that you are setting, the field 
following the prompt message will be blank. If you want to set a 
new breakpoint, backspace to erase the displayed previous 
breakpoint. You can then enter an absolute memory address, line 
number, or procedure name and press CODE-RETURN. 


If you enter a procedure name, you will be prompted with: 
Begin/End/Return: B 
The supplied default choice is B (for break at Beginning of 
procedure. If you want one of the other choices, backspace and then 
enter E (for break at End of procedure), or R (for break on Return 
from procedure). Then press CODE-RETURN. 
You wili then be prompted with: 
Break After Counts1 
Note that the debugger supplies a default value of 1, indicating 
that the break should be made the first time this breakpoint is 
encountered. If you want some other value, simply backspace to 
erase the “1” and enter the value you want. Then press CODE-RETURN. 
The debugger will output the following message: 


Entered as Break Tabie Entry #n 
The debugger maintains a table that defines the characteristics of 
each breakpoint you specify. It sequentially numbers each 
breakpoint (beinning with 0) as you specify them. You can examine 
this table using the CODE-I command. 


NOTE; A random breakpoint can be caused at any time by pressing 
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CODE-SHIFT-ESC. 


O 


THE CLEAR BREAKPOINT (CODE-C) COMMAND 


This command clears a breakpoint that you have previously set (using 
the CODE-B command). The number of the breakpoint is the number 
assigned to it by the debugger when you set the breakpoint. (You 
can check this number using CODE-1). If you enter an asterisk (#) 
instead of a number, all breakpoints will be cleared. 


THE DUPLICATE LINE (CODE-D) COMMAND 


This command causes the last line of text entered via the keyboard 
to be displayed again. 


THE EXECUTIVE (CODE-E) COMMAND 


This command causes control to be passed to the Development 
Executive interface. The prompt character for this interface (->) 
will immediately be displayed and you can then use any of the system 
utilities that are described in Appendix C. To return to Debug from 
the Development interface, press CODE-Q and then CODE-RETURN: the 
Debug prompt character {*) will be displayed. The state of your 
debugging session will remain unchanged. 


THE INFO (CODE-1) COMMAND O 


This command displays ail the breakpoints set in the break table and 
also displays the current configurations of the options and system 
memory utilization as shown in the following example: 


# Count Oceur B/E Break Location 
0000h; OFFFEH 
rReadHex;185 

B Main:Factorial:100 

R :PutChar 


oene 
Hue 


1 
2 
3 
4 


Default Module Name: CurNod 
Alternate Window: ¥ 

Memory Available (Bytes): nmnnonn 
Memory Allocated (Bytes): nnanan 


THE LOCATION DISPLAY (CODE-L) COMMAND 


This command displays the current location within the program being 
debugged. The format of the information displayed depends on the 
type of data available to the debuggers it may consist of just a 
memory address, or it may be a statement number, procedure name, 
variable name or some combination of these. 
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THE HESSAGE DISPLAY (CODE-H) COMMAND 


This command displays the current messages (if any) of the current 
(running) process. The list includes the sending process ID, the 
message class, the nate (if any) and the address for each message. 


THE OPTIONS (CODE-O) COMMAND 


This command lets you change the default module name or change the 
alternate window choice, 


THE PROCEED (CODE-P) COMMAND 


This command simply allows program execution to proceed or cantinue, 
Execution will stop either when a breakpoint is reached, when 
CODE-SHIFT-ESC is pressed, or when the program completes execution. 
You can also programmatically provide breaks by breaking on zero 
overflow, out of range, and so on by using the appropriate compiler 
controls {such as CHECK on the Pasecal-86 compiler). NOTE: you 
cannot use CODE-P to restart a program that has completed execution 
-- you must reinvoke the debugger and start from the beginning since 
control normally returns to the executive program at this point. 


THE QUIT (CODE-) COMMAND 
This command is used to exit from the debugger. Before the exit 
actually oecurs, you will be asked to confirm that you want to quit. 
THE REGISTER DISPLAY (CODE-R) COMMAND 


This command displays the contents of all the 8096 registers in the 
following format: 


AX BX cx DX SP BP SI Br 

nonnh nnnnkh nmnnnh onannh pnnoh aaanh mnanh — nannh 
EP: FL cs DS 5S i] 
Anannh oooh onnanh pnanh onoonh = nnnah 
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THE TASKS/SEMAPHORE DISPLAY (CODE-T) COMMAND @ 
This command displays a list of all processes on the process queue 
and all semaphores on the semaphore queue. The format of the 
display is shown in the following example: 


ProcID State Pri Pid/Sem Timelmt @Msgs MemUsed 


s 35al semlait 1 3508 0 0 6656 

s 3632 msgwait 1 65535 9 0 512 

s 3485 ready 1 0 0 0 43B56 

3 3799 msgWait 1 3787 0 0 512 
3787 running 128 0 0 Uy) 2896 

s 3489 ready 200 3513 0 0 64 

s 3549 loadPkg 255 0 0 0 20576 


Semal) Count Note Busy Creator 


3527 0 a 0 3485 
3503 1 0 3578 3489 
3501 0 0 65535 3489 


If a line is preceded by the letter "s", it means that the process 
on that line is a system process (actually, any process that was 
treated before yours). The ProcID column, gives the process 
identification number assigned by GRiD-O05 when the process was 
created. The State column gives the current state of each process. 
The possib > states are the following: running, ready, message wait, 
semaphore wait, timed wait, timed message wait, timed semaphore 
wait, or a loaded package (such as common). The Pri column gives 
the current priority of each process. The Pid/Sem column lists 
either the process being waited on (if in a message wait) or the 
semaphore being waited on (if in a semaphore wait). The TimeLmt 
column indicates the time remaining to wait on a timed semaphore or 
timed message wait. The #Msgs column gives the number of messages 
on the message queue of each process. The MemUsed column lists the 
bytes of memory used by each process. 


The semaphore information is Listed after the task information. The 
SemalD is the identification number assigned to the semaphore by 
GRiD-05. The Count column lists the number of processes waiting for 
each semaphore. The Note column gives the note (if any) that was 
included with each semaphore. The Busy column lists the most recent 
process waiting on each semaphore. The Creator column gives the 
identification number of the process that created each semaphore. 


THE WINDOW TOGGLE (CODE-W) COMMAND 


This command toggles or switches you back and forth between the 
debugger window or screen and the appplication window. 


O 
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COMMAND LINE COMMANDS 


The commands described in the paragraphs that follow are initiated 
by entering text via a command line in response to the prompt (#) 
character. These commands let you display the addresses and 
contents of various program locations, assign values to registers, 
memory locations and program locations, and dump the contents of 
memory. 


THE DISPLAY ADDRESG COMMAND 


To display the address of a variable, procedure, line number or 
memory location, type "@" followed by the varName, procName, line#, 
or absMem. The debugger will display an equal sign (=) followed by 
the address in the format “segmentzoftset". For example: 


@189 = O7AFh:G2A6h (19672676) 


Note that the address is displayed in both hex and decimal formats. 


THE DISPLAY CONTENTS COMMAND 


To display the contents of a variable or memory location, type the 
varName or absMem location followed by CODE-RETURN. The debugger 
will display an equal sign (=) followed by the value of the 
specified item. 


Variables are displayed according to the format they were declared 
in. For example, assume that you have declared a variable named ‘a‘ 
as follows: 

a: ARRAY [1..10] OF Char; 
You could display all characters in the array by typing the variable 
name {a} and pressing CODE-RETURN or you could display the fifth 
element in the array by typing: 

alS] 


NOTE: You can terminate the display of a long variable structures by 
pressing ESC. 


Local variables can only be displayed if you have broken within the 
Procedure where the local variables are defined. 


The contents of a specified memory location (absMem) are displayed 
as a byte value. 


You can also display the contents of a variable at one memory 
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Jocation as though it were of the type of another variable. The 


syntax for this 1s: O 


varNamel AS varName2 


This would cause the contents of varNamel to be displayed using the 
type associated with varName2. 


THE ASSIGN YALUE COMMAND 


To assign a value to a variable or memory location, type varName or 
absMem followed by an equal sign and the value to be assigned. The 
value assigned will be echoed back and displayed. for example: 


#19235: 67B=78h 
Value Assigned = 123 (7Bh, “{", true? 


Note that the value echoed back from a memory location is displayed 
in decimal, hex, ASCII interpretation (if printable), and boolean 
value. 


You can assign values to any simple type variable except Reals. If 
the value you assign is larger than the value type for varName, the 
value is truncated to the appropriate size. Values assigned to 
memory locations are assumed to be of type Byte. 


THE MEMORY DUMP COMMAND 


To display the contents of a section of memory, type the variable 
name, procedure name, line number or memory address indicating the 
starting location where the dump is to begin. Then type one space 
and a number (byteCount) indicating the number of bytes to be 
dumped. The memory contents will be displayed in tabular form with 
® values per line beginning on the line following the request, if 
the last line is short, it is filled out to a length of 8. The 
format cf each line is starting memory address (for that line), 4 
hex values, 8 ASCII values. For example: 


*O70fh:02ash 20 
Address = O78Fh:02A6h (19353478) 
O2A6h 8Rh OEh EZh OCh 49h CEh BBh Loh #....1,.-% 


O2AEh E4h OCh 42h CEh 69h Soh FA 3Bh *..B..V.5# 
O2B7h 4Eh FAh 7Fh 3Bh 89h 4Eh FBh BBh #N3.N..* 


Note that if a memory location contains a value that is not a valid, 
displayable ASCII character, a period (.) is displayed in the ASCII 
field of the dump display. 


You can terminate the display of a large memory dump by pressing 
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Esc. 


THE EXAMINE/CHANGE HEMORY COMMAND 


This command lets you sequentially examine bytes of memory and then 
either change the contents of each location or leave the contents 
unaltered, To initiate the display of memory contents, type the 
variable name, procedure name, line number, or memory address 
indicating the starting location where the examination is ta begin 
followed by an equal sign (=). After you've typed the starting 
location, the equal sign, and pressed CODE-RETURN, the memory 
address and current contents of that address will be displayed in 
hex. You can then type in a new value to replace the existing value 
or press CODE-RETURN to leave the existing value unchanged. The 
Gebugger then displays the next sequential address and its contents. 
This sequence continues until you enter a period (.) or ESC to 
terminate the command. For example: 


14t=CODE-RETURN 


O7AFh:O2A6h = BBh 7Bh CODE-RETURN 
O7AFh:O2A7h = OEh CODE-RETURN 
O7AFh:02ABh = E2h CODE-RETURN 
Q7AFh:O2A9h = OCh FFh CODE-RETURN 
O7AFh:02AAh = 7Bh , CODE-RETURN 


This sequence begins examining memory contents at line number 141 
which is at memory address O7AFh:02A6h. This starting location 
contains &Bh and the contents are then changed to 7Bh. The contents 
of the next two locations are displayed and left unchanged. The 
contents cf memory location O7AFH:OZ2A9h are changed from OCh to FFh 
and the command is then terminated after the contents of the next 
location are displayed. 
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APPENDIX A. ALTERNATE DEVELOPMENT APPROACHES 


Although the GRiDDevelon program described in Chapter 2 is powerful 
and easy to uss, there may be certain tasks or situations where you 
prefer another approach. Or, perhaps your personal preference due 
to past experience on development systems may lead you to seek a 
different, more familiar approach. To meet these needs, several 
other approaches are provided and have been used at SRiD prior to 
the availability of GRiDDevelop, 


Let‘s now look at alternatives to GRiDDevelop: the Development 
Executive program and command i*Com™) files used with the Do 
program, 
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USING THE DEVELOPMENT EXECUTIVE PROGRAM 


The DevelopmentExecutive program is a command line interpreter that @ 
lets you enter text strings to initiate commands. The system utility 
programs (described in Appendix C) comprise the commands that you 

enter via the command line. NOTE: In this context, the compilers 

and the linker program can also be considered as “utilities" and can 

be invoked from the command line. 


You get into the DevelopmentExecutive pragram by selecting it trom 
the File form. The DevelopmentExecutive interface displays an arrow 
as its prompt symbol and the prompt symbo] is accompanied by a 
linking triangle -- the system cursor. Figure A-1 shows the screen 
displayed by the DevelopmentExecutive program. 


lesion 3.4.4 af CCOS 
lopment Executive for CCOS > 


Figure A-1!. The DevelopmentExecutive Interface 


Whenever the prompt symbol and the cursor are displayed, you can 
enter text ta specify the utility program that is to be run and any 
parameters that the program requires. The cursor shows you where 
the next character you type will appear on the screen. You can edit 
the command line by moving the cursor using the leftarrow and 
rightArrow keys and erasing entries or portions of entries with the 
BACKSPACE key. You can retrieve the last command line entered by 
pressing CODE-D. 


The command line is terminated and the command presented to the 
system by pressing RETURN or CODE-RETURN. Thus, only a single 
command at a time can be issued via the DevelopmentExecutive. 
Therefore, in order to compile several modules, you have to invoke 
the compiler from the command line for each module after the 
preceding moduie compilation had been completed. Then, you must 
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USING THE 


type in the lengthy linker invocation sequence from the command 
line. Tf any errors are encountered along the way, you must repeat 
the entire sequence, performing each step one at a time. 
Fortunately, there is a way of simplifying this procedure while 
using the DevelopmentExecutive. You can create command (“Com*) 
files and initiate them from via the command line interpreter or by 
selecting them from the File form, 


DO PROGRAM WITH COMMAND FILES 


The Do program lets you execute a prearranged sequence of commands 
contained in a special file -- a command file. The Do program reads 
the commands from the file and presents them one at a time to the 
command line interpreter of the DevelopmentExecutive as though you 
were typing them in via the keyboard. A command file can contain a 
single command, a command with a long list of parameters, or 
mulltiple sequences of commands. Thus, command files save you time 
and effort by letting you create ‘canned’, reusable command 
sequences, 


To create a command file, follow these steps: 


1. Using GRiDWrite, create a file that has each command (and any 
parameters) on its own line. 


2. End each command line with a carriage return, Note: Be sure that 
you put a carriage return in at the end af the last line. 


3. Save the file specifying a Kind of “Com*. 


To execute a command file from the DevelopmentExecutive, type the 
command Do and follow it with the file's pathname. You don’t have 
to include the kind -~ “Com”. The execution syntax is: 


Do pathname 


Let's look at an example which illustrates the power of command 
files to simplify the program development process. Earlier in this 
chapter, we gave examples of compiler invocations and a linker 
invocation initiated from the DevelopmentExecutive command line. 
The two compiler invocation commands and the linker invocation could 
all be placed in a single command file that would look like this: 


Pascal ‘wO'MyPrograms Shell.Pas*Text™ 

PLM ‘wO'MyProgram*FormsInit.Plm*Text™ 

LINK ‘wO'MyPrograms*Shell,Pas*Obi*, 
‘wO'MyPrograms'Formsinit.Flm*Obj*, ‘wO‘Libs DataForms.Pas*Obi*, 
‘wO Libs‘ largeException. Asm*0bj*, 

“wO Libs’ LargeSystemCalls*Lib* TQ ‘wO'MyPrograms ‘Shell *Run® 
BIND PURBE FASTLOAD PC(PURGE) MAP ss(stack(+1500)) 


if this command file were named ‘wO'MyProgram’CampileLink”Cam*, you 
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could cause the entire sequence to be executed by issuing the 
following command to the DevelopmentExecutive: oO 


De ‘wO'MyPrograms CompileLink 


First, the Pascal compiler would be invoked and the file 
Shell.Pas*Text™ compiled. Next, the PLM compiler would be invoked 
and the file FormsInit.Plm*Text® compiled. Finally, the linker 
would be invoked and all the indicated modules would be linked 
together, 


You can enter comments inte a command file by placing each comment 
on its own line and making the first character a semicolon (;) 
character. The semicolon tells the Do program that the line is not 
executable. This capability is handy for “commenting out" selected 
parts of the canmand file, For instance, if the file 
FormsInit.Fim’Text™ had mot been changed since the last time it was 
compiled, you could skip that command by inserting a semicolon in 
front of it. The command file would then took like this” 


Pascal ‘wO'MyPrograms'Shell.Pas*Text™ 

yPLM wO'MyProgram’FormsInit.Pla*Text™ 

LINK ‘wO’MyPrograms”Shell.Pas™Gbj”, 

‘wO'MyPrograms FormsInit.Pim*Obj*, ‘wO Libs DataForms.Pas*Obj™, 
‘wO'Libs largeException.Asm*0bij*, 

‘wO'LibsLargeSystemsCalls“Lib* TD ‘wO'MyPrograms ‘Shell *Run™ 

BIND PURGE FASTLOAD PC(PURGE) MAP ss(stack(+1500)) O 


As the Do program reads each command (or comment) from the file, it 
displays the command on the screen. You can suppress the display of 
commands by entering the command $NOLIST in the command file on its 
own line. You can subsequently enable display of commands and 
comments by entering the command LIST in the command file. 


EXECUTING COMMAND FILES FROM THE USER INTERFACE 


Command files can be executed directly from the File form of the 
user interface. This approach is also faster since you simply fill 
in the File form and confirm -- you don’t have to type in a text 
string to initiate the command file, For example, te execute the 
command file described earlier ('wO'MyPrograms ‘CompileLink™Cam™) 
from the user interface, just fill out the File form as shown in 
Figure A-2. 
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@ ens . ko pra 


Device Hard Disk 

Subject. NyPrograms. 

Title EE pitecine t 
Kinet Con 

Password 


PP itm at 
2for help 


Figure A~2, Executing a Command File from the File Fora 


You can also execute the command file from within an application 
such as GRiDWrite using the Transfer form as shown in Figure A-3. 


Gayice 
Subject Mubroor ams 
Title 
Kind Con 
Pagsuord 
action Get new file and its application 


Exchange: Fillvin form and confirm 


Figure A-3. Executing a Command File from the Transfer Form 


Note that the next-to-last item on the Transfer form is "Next 
© action” ang the initial choice is ‘Get new file and its 
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application". In this case, the file being retrieved is the 
specified command file and “its application” is the program Do”*Run © 
Command”. 


When you want to edit a command file using GRiDWrite, you cannot 
directly retrieve the file with the File form since this would 
automatically retrieve the Do program with the file instead of 
GRidWrite, Instead, you must already be in GRiDWrite and then aust 
choose “Get new file only" for the “Next action" item on the 
Transfer menu. Figure A-4 shows the screen when issuing the 
Transfer command from GRiDWrite to retrieve a command file. 


Get new file and its application 


Device Hard Disk 
Subject i3Programs 


Title Compi tel ink O 
Kind Com 
Password 


Next action (Get Trev Fite ons 1 


Exchange Fill in form and confirm 


Figure A-4, Retrieving a Command File from the GRiOWrite Transfer 
Fora 
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APPENDIX B. PROGRAM OVERLAYS 


Overlays let you design programs that use the minimum amount of RAM 
(Random Access Memory) and thus make the maximum amount of RAM space 
available for data, This is accomplished by having only a part of a 
Program (the “root” module) present in memory at all times. You 
bring other parts of the the program (the overlays) into memory only 
when they are needed to perform a particular activity. When an 
overlay is not being used, it is stored on a mass storage device 
(bubble memory, hard disk, or floppy disk). When an overlay is no 
longer needed in memory, it can be unloaded from memory and another 
overlay brought into the same, or overlapping memory space. 


The penalties paid for this more efficient use of aemory are reduced 
speed (when an overlay module is needed, it must be read into memory 
from the storage device) and slightly more complicated debugging and 
dinking procedures. If your application demands a Greater amount of 
memory for data and can tolerate the performance reductions inherent 
with overiays, you can utilize the overlay capabilities provided by 
GRID OS and implemented using the Linker frogram. The purpose of 
this appendix is to clarify the additional factors introduced into 
Program structure and linking operations by the use of overlays. 


THE OSOVERLAY PROCEDURE 


This GRiD-OS call loads a specified overlay program module into 
memory. Only one level of overlays is allowed (a Program that has 
been brought into memory as an overlay cannot then issue an 
QsOverlay call). This routine can be called only from the root 
(non-overlaid) module which must be present in memory at all times. 
The format for the call is: 


PROCEDURE OsOverlay (VAR name : ShortString; 
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pid : Word; 
VAR error : Word); 


Parameters 


fame -~ @ ShortString record containing the name of the 
overlay. The overlay name is defined using the linker 
overlay control (See chapter 4 for details). 

pid ~- the process ID of the overlay. Usually, this will be 
the same as the pid returned by OsWhoAm]; that is, the 
overlay is part of the same process that is issuing the 
OsOverLay call. 

error -- the number of any error encountered while calling the 
overlay. 


This procedure call is straightforward and does not add much to the 
complexity of a program. The only consideration you must remember 
is that you can use this call only from the root module, 


WARNING: When an overlay module is loaded into memory, the previous 
overlay’s code and data segments are overwritten. Therefore, vou 
cannot have any static variables in the data segment of an overlay: 
they must be in the root module. 


PASCAL OVERLAY EXAMPLE 


Three Pascal program modules (SampieRoot, SampleOverdayi, and 
SampleQverlay2) are shown below. During execution of SampleRcot, 
each of the overlays is loaded into memory (using the GsOverlay 
call) and then the procedures DoSampleOverlay! and DoSampleDverlay2 
in the overlays are executed, 


MODULE SampleRoot; 

INCLUDE ('w'Incs’ Common, Inc*Text™) 
SINCLUDE ('w'Incs'QsFasTypes.Inc’Text™) 
SINCLUDE (‘w'Incs'OsPasProcs. Inc™’Text™) 
FINCLUDE f'w'Ines'StringTypes.Inc*Text*) 
INCLUDE ('w' Ines StringProcs. Inc*Text™) 


PUBLIC SampleOverlayl; 
PROCEDURE DoSampleQverlay1; 


PUBLIC SampleOverlay2; 
PROCEDURE DoSampleOQverlay2: 


PROGRAM SampleRoot (INPUT, OUTPUT); 


VAR error : WORD; 
avil, ovl2 : stringptr; 
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FUNCTION LoadMyOverlay (ovi: StringPtr) : BOOLEAN 
BEGIN 
ovi*.dumny := avi*,len: 
OsOverlay (ovl*.dummy, OSWhoAmI, error); 
LoadMyOverlay := (error = okCode); 
END; 


BEGIN 
WRITELN('IT am the root’); 
ovll := NewStringlit (‘SampleOveriay')3; 
IF LoacMyOverlay (ovli) THEN DoSampleOverlay!; 
ovl2 := NewStringLit (’SampleDverlay‘); 
IF LoadMyOverlay (ovl2) THEN DoSampleQverlay? 
OsExitterror); 

END. 


#ae# This is SampleOverlayl -- A Separate Module ###e+e¥e4EE 
MODULE SampleOverlay1l; 


PUBLIC SampleDverlayt; 
PROCEDURE DoSampleOverlay1; 


PRIVATE SampleOverlayl; 


PROCEDURE DoSampleOveriayl; 
BEGIN 

WRITELN('I am overlay 1°); 
END; 


44% This is SampleOverlay2 -- A Separate Module ####sKREEHE 
MGDULE SampleOverlay2; 


PUBLIC SampleDverlay2; 
PROCEDURE DoSampleOverlay2; 


PRIVATE SampleOverlay2; 


PROCEDURE DoSampleQverl ay2; 
BEGIN 

WRITELN('IT am overlay 2‘); 
END; 
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LINKING OVERLAYS O 


When you use overlays, you must individually link the root module 
and each of the overlay modules and then link all of them together 
to resolve the symbols between the root and overlays. 


For example, the following sequence from a GRiDDevelop data file 
first links the module SampleRoot.Pas*Obj* with several libraries 
needed by the program, next links two overlay module files 
(SampleOverlayl.Pas*Obj* and SampleOverlayZ.Pas*Obj™), and finally 
links the root module with the two overlay modules. 


kink: LINK SampleRoot,Pas*Obj*, ‘w'Libs’ pBirn0*1ib”, 
“wLibs'paorol“tid*, “w'Libs'pBarn2“lib*, ‘w'Libs'p8arn3*lib*, 
“wins S087"Lib*, ‘w'Libs*LargeSysteaCalls*Lib*, 
‘w'Libs*DgLarge*Lnk* TO Samp}eRoot*Lnk* DVERLAY{ROOT) NOPRINT 


LINK SampleOverlay!.Pas*Obj*, ‘w'Libs' pBérnd*lib™, 

“w'Libs pGoral*lib*, ‘w'Libs pBarn2‘lib*, ‘w'Libs'paarn3*lib*, 
‘w'Libs' 8087"Lib* 10 SaspleOverlay!*Lak* OVERLAY (Saap] ever] ay1} 
ASSUNERODT (SampleRoot*Lok*) NOPRINT 


LINK SampleQver] ay2,Pas"Obj*, ‘w'Libs' pBérn0*lib*, 

“w'Libs’pBorn1*tib*, “w'Libs'pQorn2*lib™, ‘w'Libs'p@orn3*lib*, @ 
“wLibs'BOB7*Li! 10 Saspledver]ay2*Lnk* OVERLAY (SaapleDver] ay2) 

ASSUMEROOT (SaepleRoot*ink*) NOPRINT 


LINK SaspleRoat*Lnk*, SaspleDverlay!*Lnk*, Saaplelver]ay2°Lak* TD 
SaapleRant*Run* BIND SS(STACK (#15001) PC(PURGE) 


The key statements in the link commands in this example are as 
follows: 


# When linking the root module, you must specify that the resultant 
output file be designated with the control DVERLAY(ROGT). This 
tells the linker program that this module is a raot module. 


* The output files for the two overlay modules must be specified 
with the controls OVERLAY(overlayNawe) and ASSUMERDOT(rootName) 
to tell the linker program both the name of each overlay and name 
of the root module to which each will be linked. 


* The last link invocation in the command file, first must name the 
root module and then the overlay modules, and finally name the 
executable output file consisting of the three modules 
(SampleRoot, Overlay! and Overlay2) bound and linked together. 

Note: the BIND, PURGE. FASTLOAD and StackSegment (8S) controls 
should only be used in this lack link statement, O 
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O ADDITIONAL OVERLAY CONSIDERATIONS 


To obtain most efficient performance with averlays, your root 
program should keep track of which overlay is currently in 
memory. Jf you do not do this, an overlay that is already in 
memary might be called and needlessly reloaded. 


The ASSUMERGOT control, can reduce the amount of time needed to 
link and can also produce smaller resultant output files, 


When you're debugging a program with overlays, you can set 
breakpoints in the overlays but the breakpoints must be set only 
after the overlay is loaded and the breakpoints must be cleared 
before the overlay is removed. 


FORTRAN OVERLAY EXAMPLE 
This section shows a FORTRAN Program that uses OsQveriay to cal] 
two averlay subroutines, 
a#e8 This is the Root Module e#sexeeeeee 
Program Bench 
Integer*2 ivar , ner 


Integer#2 OSWHOAMI 
Integer#i INAME (4) 


DATA INAMEL /4,83,85,66,49,32/ 
DATA INAME2 /4,83,85,66,50,32/ 


ivar - oswhoami () 

call osoverlay{INAME!,%VALfivar) ,ner) 
if (mer .eg. 9} call subi 

call osoverlay (INAME2,4%VAL (ivar) ,ner) 
if (ner .eq. 0) call sub2 

STOP 

END 


+448 This is the OverLayi Module -- A Separate Module #4#eseeenes 


subroutine subl 

Character#! big(10000) 

big(l) = ‘a’ 

big(10000) = ‘2° 

write(6,1,1OSTAT=10S,ERR=100) big(1) , big(10000) 
format(’ big start and stop subl’,al,2x,al} 
retura 


O WRITE(4,105) Ios 
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FORMAT(‘1/0 STATUS = ',16) 
RETURN 
end 


e#2* This ig the GverLay2 Module -- A Separate Module #xtteeeeeee 


subroutine sub2 

character#i big(1000Q) 

big(1) = ‘a’ 

bigttGeeo) = ‘2° 

write(6,1,10STAT=IOS,ERR=100) big(i) , big (10000) 
format(‘ big start and stop sub2’,al,2s,al) 


return 

WRITE (6,165) 105 

FORMAT( ‘I/O STATUS = ‘,I6) 
RETURN 

end 


The following sequence from a GRiDD2velop data file first links 
the madule Bench. ftn’Oby* with several libreries needed by the 
program, next links two overlay module files (Subi,ftn*Obj” and 
Sub2.ftn*Obj™), and finally links the root module with the twa 
overlay modules. 


The link commands for these FORTRAN overiay modules would be as 
follows: 


Link Bench. ftn*obj*, “w'Libs FA6RNO*LIB*, ‘w'Libs’ FSbRMI*LIB™, 
“wLibs FBSRN2*LIB™, “w'Libs FOGRNZ°LIB*, ‘w Libs’ FRGRNA*LIB*, 
‘wiLibs CELA7*LIB™, ‘w'Libs EHO7°LI8*, ‘w'Libs’S087*LIB*, 
w'Libs DCONS7*LIB, ‘w Libs ‘LargeSystenCalls*Lib*, 

w Libs DgLarge*Lok* 70 Bench*Lok™ OVERLAY(RODT) NOPRINT 


Link Subl.fta*obs*, ‘wLibs FRGRNO’LIB™, ‘w'Libs*FBSRKI“LIB*, 
“w'Libs*FOGAN2*LIB™, “w'Libs"FBORNS*LIB*, “w'Libs’ FBERNA*L1B", 
“w'kibs CELG7*LIB*, ‘w'Libs EHB7*LI8*, ‘w'Libs"B087LIB*, 
“wkibs DCOM@7*LIB*, ‘w'tibs'DgLarge*Lnk* 10 Subi*Lnk™ 
OVERLAY (Sub1} ASSUMERGOT (Bench*Lnk*) NOPRINT 


Link Sub2.ftn*obj*, ‘#'Libs FBGRNO*LIB*, ‘w'Libs’FOSRNI*LIB*, 
‘w Libs FRORN2"LIB*, “w'Libs FBORNZ°LIB”, “w'Libs’FO6RN4*LIB*, 
‘w Libs *CELB7*LIB™, ‘w'Libs EHB7*LIB™, ‘w'Libs’BOB7*LIB™, 
w'Libs' OCONG7"LIB*, ‘w'Libs'DgLarge*ink* TD Sub2“Lnk* 
OVERLAY (Sub2) ASSUMERDDT ‘Bench"Lak*) NOPRIAT 


{INK Bench"ink™, SubJ*Lnk*, Sub2*Lnk* TQ Bench*Run™ BIND 
SS{STACK(+1500)) PC (PURGE! 
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APPENDIX C, SYSTEM FILES AND UTILITIES 


This appendia ad 
utility program 
housekeeping. 

described here 
real need to us 
utility, you sh 


The system util 
the command lin 
current subject 


escribes the system files that the SRiD Compass uses and the 

Ss available to assist you during program development and systea 
NOTE: Most of the tasks performed by the utility programs 

can be handled more easily by GRiDManager. Unless you have a 
e the command line interpreter or a need for a specific 

ould use GRiDManager. 


ity programs cperate on devices and files and are invoked via 
e interpreter. You can run any of them without regard to the 
since they are under the Programs subject, 


SYNTAX NOTATION 


Synta 
conve: 


x notation in this appendix operates under the following 
ations. 


* Keywords (command or function names) are in capital letters. 
Exampies: CAT, DUMP, 


* Parameters are in lowercase letters, 
Example: PREFIX pathname. 


* Square brackets enclose optional parameters. 
Example: CAT (pathname). 


* Braces or curley brackets surround a choice of parameters 
with each parameter separated by a vertical slash. 
Example: (realtinteger). 


If a parameter choice is an option, you would surround the 


choice with square brackets. 
Example: {{reallinteger}J. 
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A note on syntax statements: you must enter parameters in the order 
given in the syntax statement. 


ENTERING COMMANDS 


WILDCARDS 


Throughout this appendix we use uppercase letters in writing about 
commands. As stated above, in the case of syntax notation, command 
names are in all uppercase. When discussing a command in a 
sentence, the first letter will be capitalized. For example, "Only 
the Cat command recognizes the wildcard character." 


However, you can enter commands, program names, and file pathnames 
in any form you want wih regard to capitalization. The system 
understands "CAT," "cat," and even "cAt" as the same command. 


Some of the utilities recognize one wildcard character -- the 
asterisk (#). You can substitute one wildcard for any character, for 
any string of characters, or for no character(s). Wildcards work 
only with the Cat program. 


For example, let's say you have five titles under ‘w'Morebees -- 
Brains, Brass, Barrooms, Beanbag, and Edna. Typing a command and 
following it with ‘w'Morebees'B#S would cause the command to act on 
all the file names that begin with B and end with S: Brains, Brass, 
and Barrooms. Beanbag fails because it doesn’t end with 8, and Edna 
neither begins with B, nor ends with S. B* would cause the command 
to execute on all files except Edna. 


A pathname consisting of an asterisk only will act on all files that 
exist under the current prefix, 


THE @SYSTEMERRORS FILE 


The file named @SystemErrors™text” in the Programs subject contains 
the text that is displayed when a system error is encountered. If 
this file is not present, an error number will still be displayed 
when errors are encountered, but there will be no explanatory 
message with the number. 


THE ACTIVATE PROGRAM 


This program activates a new device and adds it to the list of 
currently active devices. ‘Activating’ a device consists of 
associating a device name that you specify with the appropriate 
device driver program and GPIB address. The operating system 
automatically activates the following devices whenever the system is 
booted: 
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device name GPIB addr (hex) 


Floppy Disk 0005 
Bubble Memory none 
Hard Disk 0004 


Portable Floppy 0006 
Extra Hard Disk 000c 
Extra Floppy Disk 000D 


gpib none 
bb (bit bucket) fone 
ci (console in) none 


to (console out) hone 


If a device is not physically present, it is not activated. 
However, you can later activate a device using the “Add a device” 
command from GRiDManager, The currently active devices will be 
displayed on the File form. 


The driver programs for local mass storage devices are incorporated 
into the operating system and do nat exist as separate files. The 
Modem file is under the Programs subject and its kind is “Device”, 
The Modem can be activated simply by selecting the file Title Modem 
from the File form or by typing the command 

Activate Modem 
Similarly, you can activate the serial driver by typing 

Activate Serial 
If you need to activate a device whose driver prograa does not exist 
aS a separate program, the syntax you must use with Activate is the 
more complicated form shown below: 

ACTIVATE DEVICE device! AS device2 Em] [gpib-addr] 
This will look for device! in the active device table and will use 
that device driver to create another device called device2. For 
example, if you were connecting a second hard disk to your system, 
you could activate that device as follows: 

ACTIVATE DEVICE ‘Hard Disk’ AS ‘Second Disk’ m 6 


This would activate the second hard disk and assign it the device 
name Second Disk with a GPIB address of 4, 
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THE CAT (CATALOG) PROGRAM 


The program lists all the titles in the subject directory, relative 
to the file level you have specified. You can cause the program ta 
print the requested directory to some device other than the screen 
{including a text file} by specifying a second pathname. Here 2s 
the complete syntax: 


CAT Cpathnamel] (pathname?) ['1] [73 
Typing the Cat program name without parameters will cause the 
program ta display all the titles under the current subject in a 
tabular form somewhat like the one below (all numbers are in 
decimal): 


Files matching ‘w'nystuff'* 


File Name Length Last Modified 
Gridstar.1*Worksheet~ 107) 03/16/82 09:45 
Statusform*text™ 243 02/28/82 15:12 
Forecast, 1*Text™ 1468 O3/03/82 11:47 


storage utilization: 1661/10404 pages, 15.9% 


The first line tells the device (‘w), subject (‘mystuff), and title 
description (* ~- the wildcard) for the titles on the screen. The 
first column displays these titles. 


The second column displays the number of bytes that each file 
occupies. 


e 
The first number after “storage utilization" indicates the total 
number of pages taken by all files on the bubble, diskette or disk. 


The second number shows the total number of pages on the bubble, 
diskette or disk. To find the number of free pages available, 
subtract the first number from the second. 


The third number is the percentage of occupied pages to the total 
number of pages available on the device. 


When the file names are being displayed on the screen, you can stop 
scrolling by typing CTRL-S. To restart scrolling, press CTRL-S 
again. Pressing CODE-ESC cancels the Cat program and thus the 
scrolling. 


Note that when you enter Cat without a pathname, the Cat program 
puts in an invisible wildcard character that defaults to the current 
device/subject prefix and all the titles within that subject. for 
example, if your current prefix were ‘w Breakfast, the first line of 
your catalog display would read: 


Files matching ‘w'Breakfast’* 
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However, if you wanted te lock at a different prefa grouping. like 
“f*Lunck, you would have to enter this explicitly or change vour 
prefi: first, Yo see al! the titles under this prefix, you would 
typer 


Cat ‘Ff Lunch’# 


Creating a Catalog File 


The Cat program lets you specify a second pathname if you want to 
send your catalog information to a text file instead of to the 
screen, We cal) this file a "catalog file." This file can be sent 
to either disk or te an output device, such as a printer, The 
Program prepares the file during execution, 


Nete that the syntax for a catalog file requires that you precede 
the name of the catalog file with a pathname for the tities(s! you 
want cataloged, At a minimum, this pathname must be the asterisk 
On, 


For example, typing Cat * Catchall would create a file called 
Catchall and write into it all titles under the default prefix. 
Simitarly Cat BB¥.COM BEBEFILE would create a file under the default 
Prefix catied BEBEFILE and put in it all titles beginning with the 
letters BB and ending with .COM, 


By preceding the name of the catalog file with a device name, you 
tan direct where the system will send the catalog file. Without the 
device name, the system will set ua the file an the default device, 


! (Exclamation Point) 
Placing the exclamation point after Cat (or after Cat and any of its 
Perameters) will cause the Czt program to display file titles 
Without File lengths and dates and times, As a result, the 
erclamation point causes the catalog to display much more rapidly. 
? Question Mark 
Placing the question mark after Cat and 2 title will cause the Cat 


Program to search for that title under every subject on the 
currently pretixed device. 
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THE COMPARE PROGRAH QO 


This program compares two files for equality or inequality and is 
useful for checking if two files are duplicates. The syntax is 
sinply: 


COMPARE filel file2 


If the two files are identical, the program displays the word 
"Same", 1f they are not identical, the word “Different” is 
displayed. 


THE DEACTIVATE PROGRAM 


This program will deactivate a device, removing it from the active 
device table. Refer to the Activate program for a discussion of 
devices and device activation. The syntax for this program is 
simply: 


DEACTIVATE dev 


where "dev" is the device name as listed in the active device table 
(see the LADT program). 


NOTE: You should not usualiy deactivate any of the devices that are 
automaticaily activated by the system during power up (Floppy Disk, @ 
Hard Disk, Buoble Memory, etc.)., The drivers for these devices are 
incorporated into the operating system software and do not exist as 
separate files. They therefore can not be reactivated using the 

Activate program described earlier in this chapter. 


THE DEVELOPMENT EXECUTIVE PROGRAM 


The DevelopmentExecutive*Run™ file under the Programs subject is the 
program that provides the command line interpreter. Refer to 
Appendix A for a discussion of the DevelopmentExecutive interface, 


THE DO PROGRAM 


Do*Run Com” is the program that lets you execute a command file 

The Do program reads the commands from the file and presents them to 
the system as though you were typing them in at the command line of 
the development interface. Thus, command files save you time and 
effort by letting you create ‘canned’, reusable command sequences. 
for a discussion of command files and the Do program, refer to 
Appendix A. 
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THE DUMP PROGRAM 


The Dump program send the contents of a file in both REX and ASCII 
to a specified destination file. If no destination file is 
specified, the contents are dumped to the screen, The syntax for 
this program iss 


DUMP sourceFile CdestFiled 


The information that follows is an example of a dump of the 
System, init™tom™ file: 


FILE = system.init*Com™ 


0000 24 6E 6F 6C 49 73 74 OD OA 61 63 74 6F 7h BE 74 
eEnolist..activata 

O010 65 20 6D OF 64 65 6D OD OA 24 20 60 77 30 40 70 4e 
modem..' ‘w'p* 

0020 72 6F 67 72 61 6D 73 60 73 63 72 65 65 BE 77 61 
*rograms Screenwa* 

0030 74 63 68 7E 72 75 £ 7E OD OA OD oA 

#ECH*run™ sae * 


END OF FILE 


The four-digit numbers at the left of each row are the byte count 
(in heaxadecimal) of the first character in that row. Thus the 
first character ia the second row (hex 65) is byte number 0010 
(hexadecimal) in the file. Next, the hexadecimal representation of 
each byt2 in the file is provided, with 16 bytes displayed in each 
row. To the right, the ASCII representation of each byte is 
displayed, 


THE ELAPSED TIME PROGRAM 


This program times the execution of any program you specify. The 
syntax is: 


ELAPSEDTIME pathName 


where pathName specifies some executable file. After the specified 
program has completed execution, control is returned to the 
Gevelopment interface and the time that elapsed since you invoked 
the program is displeyed. 


THE EXECUTIVE FILE 


This file is loaded into memory whenever the system is booted. It 
displays the initial File form and is required in order to perform 
such as activities a5 exchanging files. 
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THE LOAD PROGRAM 
The Load program simpiy loads an executable module into memory. 


LOAD pathkame 


THE WODEM DEVICE FILE 


The file under the Programs subject named Medem“Device~ contains the 
device driver for the Compass Computer internal medem. Usvelly, the 
systen automstizally activates the modem as part of its 
initializetion sequence. You can directly enable or disable the 
modem using the Activate or Deactivate programs. 


THE PREFIX PROGRAM 


When you boot the system, the default subject is always Programs 
and the cevice will be whichever device ycu directed the system to 
-- bubble, hard disk, or floppy. (If you did not explictly specify 
a device -- by halding down the ‘H’ or ‘F’ key during the boot 
sequence -- the svstem first tries the bubble, then the hard disk 
and finally the floppy, until it finds ona of those devices ready.) 


When speaking in terms of pathnames, we refer to the initial 

‘device subject pair as the "default prefix." By "default," we mear 
that any time the system must access a file, it will try to find the 
file in question under the defeult prefix, untess told to Icok 
elsewhere. By "prefix", we mean the device-subiject pair. 


You can override the default prefix by explicitly typing another 
prefiy before a title. To reset the prefix to a differant device 
pair altogether, uze the Prefix program. 


To evacute the program, type Prefix, a space, and the name of the 
new default prefix (both the physical device and 2 subject, i.e., 
‘ft lunch). Finally. press RETURN. Nete thet a tick should not 
follow the sutject name. The default will remain with the new pair, 
until you give the syst a different pair by reinvoking the Prefix 
program. Tre syntax is simole: ‘ 


PREFIX (device Isubject 


For example, Prefix ‘f*Programs will cause any further storage 
access to lost ta the floppy drive, under the subject "Frograas.” 
Typing Prefix ‘w'Breakfast will change the default so that 
subsequent searches for titles (whether to read from them or write 
to them) to the subject called Breakfast. 
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Note that the device is optional when specifying a new prefix, If 
you do not include a device rame. the new prefix will become the 
specified subject combined with the previously prefixed device. 
Thus, :f the current prefix 13 ‘w'Breakfast, typing Prefix Lunch 
will change the default prefix to ‘w Lunch, 


THE SOFTKEYS FILES 


The numeric keys on the keyboard have been proorammed to generate 
often used words and symbols at the the command line level, that is, 
from the development interface. For example, typing CODE-SHIFT-4 
will print the word “Pascal" on the screen. Likewise, pressing 
CODE-3 will cause “Programs*" to appear. 


Thus, these teys let you quickly generate frequently used command 
Messages. The following tabie shows all preprogrammed softkey 
messages and the key combinations for generating them, 


REY CODE CODE-SHIST 


1 ‘"Flappy Disk** 

2 “‘Hard Disk’ * 

3 Programs‘ 

4 ‘Bubble Memory’* Pascal 

3 ‘"Portable Floppy’* PLM 

6 BRiDWrite Fortran 
Z “Text™ 

8 “Lst* ‘Printer 
¢: “Con” “Worksheet™ 
i) *Run™ “Graph™ 
= Prefix 


Table C-1, Preprogrammed Softkeys 


Prograorming the Softkeys 


You can substitute your own aessage(s) for any current softkey 
messages. To do this, edit the file ‘w'Programs'SoftKeys*Text*, 
This file contains each aessage (beginning with ""f*" and ending 
with "Cat") separated by a carriage return. Select a message for 
replacement and erase it. Then type your substitute message in its 
place. Save the revised file, 


To activate your new message(s), you must load the revised file. 


You have two ways of doing this: either type CODE-= or reboot the 
system by pressing the reset button. 
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Your mew message will appear whenever you press the key combination 
that draws its characters from the position in which you placed your ‘@) 
message. For example, if you replaced "Fortran" with a favorite 

subject name, "MyStuff," you would see "MyStuff" every time you 

pressed CODE-SHIFT~-é, 


Multiple Softkey Files 


You can place different ‘Softkeys*Text™ files under different 
subjects. Each file can have entirely different messages. In such 
acase, the file's messages will be available only when you're in 
that file’s subject. Whenever a subject does not have its own 
Softkeys file, it will draw messages from the SoftKeys file in the 
subject "Programs." 


To activate the Softkeys file in a subject other than "Programs," 
type CODE~=, If you don’t issue this command, any use of the the 
softkeys will default to Programs’s Softkeys file. 


THE STATUS PROGRAM 


This program displays system status information including memory 
utilization, the current prefix, and currently loaded packages. To 

run the program, simply type STATUS and press RETURN. The 

information displayed will be similar to that shown below: ‘o) 


Nersion 3.8.4 of Ccos 

evelopment Executive for CCOS >= 34.4. 19 
Sb shabus 

“rrent prefix: ‘Hard Disk*Programs 


total free twtes: 93536 

Waber of Free blocks: 13 
largest free block* 65535 

total allocated butes: 1az6ge 
umber of allocated blocks: 165 
largest allocated block: 65535 
a“ 
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THE SUMMARIZE PROGRAM 


This program analyzes a file's usage of memory and displays the 
results of that analysis. The syntax is: 


SUMMARIZE sourcePathName {destPathNamel C'commentString’) 


The sourcoPathName specifies the file that is to be summarized, The 
results of the summary will always be displayed on the screen. The 
optional destPathName lets you specify that the results also be sent 
ta another destination ~- typically the printer. The optional 

commentStriag must be enclosed in single quotation marks and will be 
displayed at the beginning of the summary information. For example: 


SUMMARIZE ‘w'programs*MyApp*run™ ‘printer ‘10-30-92 Summary’ 


This would cause the following information to be displayed on the 
screen and also printed at the printer: 


10-20-82 Summary 


File: ‘w' programs ‘MyApp*run™ 
Initialization: 17 272 
Code/Const: 94 94679 (8927) 
Fixup: 43 680 

Waste: ) 0 

Total: 154 10631 
Overhead: 16.0% 

Data segment: 52 

Stack segment: 1026 


The left column of numbers shows how many records are devoted to 
each category and the right column is the number of bytes in each 
category. 


THE TIME PROGRAM 


This program simply displays the current time and date maintained by 
the clock chip. To display time, simply type TIME and press RETURN. 
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THE UNLOAD PROGRAK O 


This program simply ualoads a run module that was previously LDADed 
(either explicity with the LOAD program, or by the system at boot 
time). The syntax for the Unload program iss 


UNLOAD pathName 


THE WORK PROGRAM 


This program sinply specifies the device that will be the ‘work’ 
device. The language compilers and the Link program require 
temporary work files for their operation, Additionally, system 
programmers use work files for applications that require temporary 
files. Work files are discarded upon completion of the operation 
for which they were being used. These files assume the presence of 
a virtual device named Work, The system automatically designates 
the physical device that you boot from as the Work device. If you 
want to change this default, run the Work program using the 
following syntex: 


WORK ‘dev 
If you boot your system from Bubble Memory, you might get a device 


full message when compiling programs. You should change the work @) 
device to Hard Disk if you boot from Bubble Memory. 
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APPENDIX D. LINK ERROR NESSAGES 


This appendix describes error messages that may be produced by the 
Link program. Only those errors deemed likely to occur in the 
system are listed. Should you encounter an error message generated 
by one of the Link program that is not listed here, contact the GRiD 
Customer Support Center. 


Remember, it is possible to receive an error message generated by 
the operating system (GRiD-0S) while you are running the Link 
program, Refer to the GRiD-O05 Reference manual for a complete 
listing of system error messages. 


The Link program generates both error messages and warning messages. 
They are listed in the pages that follow in numerical order with 
warning and error messages intermized. 


Error messages are always fatal: they terminate processing of the 
input file(si and halt execution of the Link program. All open 
files are closed and the contents of the print file and the object 
file are undefined. 


Warning messages are not fatal. They are listed consecutively as 


warning situations are encoutered. Read the discussion of the 
warning carefully to determine whether the resultant code is valid. 


ERROR t: 1/Q ERROR 


What happened The operating system detected an I/O error in the 
input file. 


What to do Check the pathnames specified for the input file and 
check for possible media errors. 
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ERROR 21 1/0 ERROR 


What happened The operating system detected an I/0 error in the 
print file. 


What to do Check the pathnames specified for the print file and 
check for possible media errors. 


ERROR 3: 1/0 ERROR 


What happened The operating system detected an [/0 error in the 
object file. 


What to do Check the pathnames specified for the object file and 
check for possible media errors. 


ERROR 4: 1/0 ERROR 


What happened The operating system detected an 1/0 error in the 
console file. 


What to do Check the pathnames specified for the console file 
and check for possible media errors. 


ERROR 5: INPUT PHASE ERROR 


What happened A record encountered during the second phase of 
linkage did not agree with information gathered 
during the first phase of linkage. This error is 
caused by a data transmission error or an internal 
error in the Link program itself. 


What to do Contact the GRiD Customer Support Center. Be 
prepared to provide a copy of the object file, the 


Link invocation line, and your version of the Link 
program, 


ERROR &: CHECK SUM ERROR 


What happened The check sum field at the end of one of the object 
module records indicates a transcription error. This 
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can be caused by any number of data encoding or media 


errors, 

What to do Retranslate the source that produced the specified 
object module where the error was detected, Then 
relink, 


ERROR 7: COMMAND INPUT ERROR 


What happened An error was detected while atteapting to read the 
tomplete invocation line. 


What to do Check the invocation line for errors and try again. 


WARNING 6: SEGMENT COMBINATION ERROR 


What happened Two segments with the same name can not be combined 
because they have different combination attributes or 
incompatible alignment attributes. The linker will 
Continue processing pass 1 but pass 2 will not be 
started. The resultant output obiect file is useless 
and the print file contains limited information. 


What ta do Retranslate the source that produced the specified 
file and module. Then relink, 


WARNING 91 TYPE MISHATCH 


What happened There is a public/external symbol pair for which the 
type definitions do not agree. The linker continues 
Processing using the first definition only. The 
object file and the print tile should be valid, 
except the second definition for the symbol is 
ignored. 


What to do Modify the offending public or external declaration 
and recompile and relink the source file. 


WARNING 10: DIFFERENT YALUES FOR SYMBOLS 


What happened The same symbol was declared public in two different 
madules. The specified file and module contains the 
second definition encountered. The linker continues 
Processing using the value of the first public 
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definition; the second definition ts 1gnered. Both 
the print file and the object file will be valid, oO 


What te do This situation will often occur in the normal course 
of events, for example, when you are linking library 
files along with CompactSystemCails*Lib*. In such 
cases, you can usually ignore this warning. If it is 
a problem, change the name of the symbol in either 
the specified file or in the file containing the 
earlier definition of the symbol. 


ERROR ti: INSUFFICIENT MEMORY 


What happened Because of an extensive use of public symbols, there 
is insufficient memory for the linker to build its 
internal tables and data structures. 


What to do If possible, unicad unneeded packages, such as 
common, Otherwise, try incremental linkages, That 
is, link smaller sets af files tagether using the 
NDPUBLICS control, then link the resulting composite 
modules together. 


WARNING 12: UNRESOLVED SYMBOLS @ 


What happened External symbols were declared that could not be 
resolved during this linkage. (This is quite common 
when performing an incremental linkage.) The print 
file is valid. The object file must be linked to 
resolve the external references. 


What to do Link the object file to a file that will resolve the 
external references. 


WARNING 13: IMPROPER FIXUP 


What happened An external reference makes assumptions about the 
segment register that do not agree with the 
assu@ption made for the public definition. The 
linker continues processing. The object file will 
not be usable, but the print file will be complete 
and accurate. 


What to do Try recompiling with a different model of 
segmentation, or change the source and reassemble, 
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WARNING 14; 


What happened 


What te do 


GROUP ENLARGED 


The specified group name has been defined twice in 
two different modules and the segments contained in 
the two definitions are different. The two groups 
are combined into one with all segments that were in 
either group included in the resulting group. 
Segments with the same segment rame, class name, and 
overlay name ae combined. The linker continues 
processing and both the print file and object file 
are valid, 


No action should be necessary, 


ERROR 15: LINK#S ERROR 


What happened 


What to do 


A fatal, internal error has occurred within the Link 
Program itself. 


Contact the GRiD Customer Support Center. Be 
Prepared to provide a copy of the object file, the 
invocation line, and your version of the Link 
program. 


ERROR 16: STACK OVERFLOW 


What happened 


What to do 


WARNING 17: 


What happened 


What to do 


Link’s run time stack used for type matching has 
overtlowed. This can be caused by an overly complex 
type definition of one of your symbols. 


Try incremental linkage (see error 11). If the error 
persists, contact the GRID Customer Support Center, 


SEGMENT OVERFLOW 


The combination of two or more segments has resulted 
in a segment that exceeds 64K. The linker continues 
Processing during the current pass, but the print and 
object files are not useable. 


Reorganize your segments and reassemble. 
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WARNING 18: 


What happened 


What to do 


TMPROPER START ADDRESS 


A start address was found in one of the overlay 
modules, and none was found in the root module. This 
error is often caused by misordering the input 
modules in the input list. The linker ignores the 
start address in the specified overlay aodule and 
centinues processing. 


If you want the module containing the start address 
to be the root, relink with that module first in the 
input list. 


ERROR 19: TYPE DESCRIPTION TOO LONG 


What happened 


What to do 


The type definition is too long to fit in the 
linker‘s symbol table. 


Contact the GRID Customer Support Center. Be 
prepared to provide a copy of the object file, the 
invocation line, and your version of the Link 
program, 


ERROR 22: INVALID SYNTAX. ERROR IN COMMAND TAIL NEAR # 


What happened 


What to do 


This error is usually the result of a typographical 
error in the invocation line. The partial command 
tail up to the point where the error was detected is 
printed. 


Check the invocation line and reinvoke the Link 
program more carefully. 


ERROR 23: BAD OBJECT FILE 


What happened 


What to do 


The link program has detected an inconsistency in the 
fields of a record in the specified input file. This 
error could be caused by the compiler or could be due 
to a media problem, 


Recompile and then try relinking. If the problem 
persists, contact the GRiD Customer Support Center. 


Program Devieopment Cuide 


WARNING 24: CANNOT FIND MODULE 


What happened 


What tao do 


The specified module cannot be found in the Specified 
library file. The linker continues processing as if 
the specified module was not in the list, 


If the module is important, you can link it into the 
output object file later, 


WARNING 25: EXTRA START ADDRESS IGNORED 


What happened 


What to do 


ERROR 26: NOT 


What happened 


What to do 


A start address has been encountered in more than one 
module indicating that you have specified more than 
one main module in the input list. The linker uses 
the start address encountered earlier and ignores the 
start address in the module specified here with the 
warning message. Processing continues with no other 
side effects. 


Do nothing, if the start address in the specified 
module was intended to be ignored. 


AN OBJECT FILE 


The file specified with the error message is not an 
object file. This error is usually caused by a 
typographical error in the input list. However, some 
media problems can also cause this error. 


Check the invocation line and try again. If you 
suspect media problems, try recompiling and 
relinking. 


WARNING 28: POSSIBLE QVERLAP 


What happened 


What to do 


This warning is issued when the linker combines two 
absolute segments. Processing continues with no side 
effects. 


If there is an actual conflict, the loader will 
detect the overlap. 
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ERROR 30: LIBRARY IS NOT ALLOWED WITH PUBLICSONLY CONTROL © 


What happened The file specified with the error message isa 
library file and libraries are not allowed ina 
PUBLICSONLY control. 


What to do Remove the library file from the PUBLICSONLY argument 
list and reinvoke the linker, 


WARNING 32: EXTRA REGISTER INITIALIZATION RECORD IGNORED 


What happened You have included two main modules in your input 
list. The linker uses the first register 
initialization record and ignores the second, 
Processing continues with no side effects. 


What to do If the register initialization information in the 
file specified with the warning message should be 
used instead of the first such record encountered, 
then modify your input list. Otherwise, no action is 
required. 


ERROR 33: ILLEGAL USE OF OVERLAY CONTROL 


What happened While processing input modules for an overlay, the 
linker found an overlay definition in the file and 
module specified with the error message. A module 
being used for an overlay cannot itself specify an 
overlay. 


What to do Remove the specified file from the input list and 
relink. 


ERROR 34: TOO MANY OVERLAYS IN INPUT FILE 


What happened The file and module specified with the error message 
contains more than one overlay definition. 


What to do Remove the specified file from the input list or 


correct the file so that it has only one overlay 
definition. Then relink. 
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ERROR 35: SAME OVERLAY NAME IN TWO OVERLAYS 


What happened 


What to do 


The file specified with the error message contains an 
overlay that has the same name as an oversay already 
encountered in the input list. 


Remove one of the duplicate names from the input jist 
and relink. I¥ both overlays are needed, relink one 
of them specitying a different overlay name, 


ERROR 34: ILLEGAL OVERLAY CONSTRUCTION 


What happened 


What to do 


WARNING 373 


What happened 


What to do 


Some of the modules in the input list contain overlay 
definitions while others do not. This is illegal: 
all modules in the input list must be the same with 
respect to averiays. 


Remove the non-overiay files and relink, 


DIFFERENT PUBLICS FOR EXTERNAL IN ROOT 


The linker has found two symbol definitions in the 
overlay modules that resolve the same external symbal 
definition in the root. The definition in the file 
and module specified with the warning message is 
ignored and processing continiues with no side 
effects. 


Remove the unwanted symbol definition and relink. 


ERROR 41: SPECIFIED SEGMENT NOT FOUND IN INPUT MODULE 


What happened 


What to do 


WARNING 423 


What happened 


This error is usually caused by a typographical error 
in the SEGSIZE control. 


Check the input list for accuracy and, if needed, 


find the module that contains the specified segment 
and add it to the input list, 


DECREASING SIZE OF SEGMENT 


The size change specitied in SEGSIZE has caused the 
linker to decrease the size of the specified segment. 
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Decreasing the size of a segment can cause sections 

of code to be unaccounted for during the memory ‘@) 
allocation process, Processing continues with no 

side effects, 


What to do This is usually caused by leaving of the plus sign in 
the SEGSIZE(STACKtnnnn)? control. Check the input 
list anc correct, 


ERROR 43: SEGMENT SIZE OVERFLOW; OLD SIZE+CHANGE > 64K 


What happened The size change specified in the 
SEGSIZE(STACK(+nnann)) control caused the segment to 
become greater than 44K. 


What to do Reinvoke the linker with the correct 
SEGSIZE(STACK(+nnnn)) control. 


ERROR 44: SEGMENT BIZE UNDERFLOW) OLD SIZE+CHANGE < 0 


What happened The size change specified in the 
SEGSIZE(STACK(+nnnn)) control caused the segment to 
become less than zero. a] 


What to do Reinveke the linker with the correct 
SEGSIZE(STACK(+nonn)) control. 


WARNING 47: GROUP HAS NO CONSTITUENT SEGMENTS 


What happened The group specified with the warning message has no 
segments and is not placed in the output object file. 
This errar is often the result of a typographical 
error in the invocation line. The group is left out 
of the object file and processing continues. 


What to do Unless there is a particular need for the specified 
group, mo action is necessary. 


WARNING 48; SIZE OF GROUP EXCEEDS 64K 


What happened All of the segments that belong to the group 
specified with the warning message do not fit within 
the physical segment defined for that group. This 
error is usually caused by misuse of the SEGSIZE ) 
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WARNING 523 


What happened 


What to do 


control. The linker includes all segments in the 
object file and continues processing the input 
oodule. The output module will be executable, 
although addressing errors may occur. 


Examine the invocation line and reinvoke the linker 
using the SEGSIZE control more carefully. 


OFFSET FIXUP OVERFLOW 


While computing an offset from a base, the linker 
found that the offset was greater than 64K. This is 
a result of one of the segments of the group being 
outside the 64K frame of reference defined by its 
group base. The linker continues processing and the 
Print file will be valid. The output file, however, 
with regard to the out of place segment, will not be 
usable, 


Modify the group definitions in your source file, 
retranslate and relink. 


ERROR 5S: ILLEGAL FIXUP 


What happened 


What to do 


What happened 


What to do 


While processing a fixup record, the linker found 
that the base for the reference and target are 
different. This is usually a coding error, 


Check your source carefully, retranslate and relink. 


NO START ADDRESS SPECIFIED IN INPUT MODULES 


The BIND control was specified, and none of the input 
modules has a start address. This indicates that the 
input list contains no main module. The CS and IP 
registers remain uninitialized, and their values are 
dependent on your system loader. The object module 
will be valid. 


Reinvoke the linker with a main module. 
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ERROR 60: OUTPUT FILE 1S SAME AS INPUT FILE 


What happened The pathname of the input file spacified with the 
error message is identical to the cutput file 
pathname. 


What to do Fix the duplicate-name situation and reinvoke the 
linker. 


WARNING 64: PUBLIC SYMBOLS NOT SORTED DUE TO INEUFFICIENT MEMORY 


What happened The number of public symbols in the input-list 
modules is too large for the linker to sort with 
available memory resources. The print file lists the 
public symbols in the order in which they were 
encountered in the input files. This condition has 
no effect on the correctness or validity of the 
cutput object module. 


What to do Increase the amount of available RAM {for example, by 
unloading unneeded packages) or decrease the number 
of public symbols. 


WARNING 65: ILLEGAL FIXUP: INCORRECT DECLARATION OF EXTERNAL 
SYMBOL 


What happened The declaration of the symbol specified with the 
warning message Was inconsistent with a corresponding 
public symbol definition and the linker could not 
resolve the reference. This condition is usually 
caused by an attempt to access absolute entry points 
from pre-located code without using the PUBLICSONLY 
control explicitly, The linker internally converts 
these illegal fixups to legal formats to identify all 
becurrences in a singte execution. Thus the output 
object module may not be correct, although it will be 
a valid 9086 object module. 


What to do If the warning occurred because of an attempted 
access of absolute entry points from pre-located 
code, use the PUBLICSONLY control in conjunction with 
the file that contains public definitions for those 
entry points. 
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WARNING 69: 


What happened 


What to do 


WARNING 713 


What happened 


What to do 


WARNING 721 
IBNORED 


What happened 


What to do 


WARNING 743 


What happened 


What to do 


OVERLAPPING DATA RECORDS 


The FASTLOAD control was specified, and two data 
records belonging to the same segment have offsets 
which make them overlapping. This is usually the 
result of a translation error, unless you have 
intentionally overlapped data records. The linker 
ignores the second record and does not include it in 
the output file. The code will be unusable. 


Tf you want an overlap condition to exist, reinvoke 
the linker but do not use the FASTLOAD control. 
Otherwise, retranslate, then reinvoke the linker. 


TOO HANY MAIN MODULES IN INPUT 


There are two or more main modules (modules with 
start address) in the input list. The linker uses 
the start address of the first main module it reads 
and ignores the others. The object code will be 
valid. 


Make sure that the linker’s interpretation is 
suitable to your objectives. If not, modify the 
input list and relink, 


REGISTER INITIALIZATION CODE EXISTS, NEW INITIALIZATION 


Because of a translation or linker problem, two or 
more initialization codes for 8084 registers were 
encountered in the input list, The linker uses the 
first initialization code and ignores the others. 
The object code will be valid. 


If retranslating of relinking does not correct the 
error, contact the GRiD Customer Support Center. 


PRINT FILE SAME AS INPUT FILE 


The pathnames of the print file and one cf the input 
files are identical. 


Fix the duplicate-name situation and reinvoke the 
linker. 
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ERROR 75: PRINT FILE SAME AS OUTPUT FILE 


What happened The pathnames of the print file and the output file 
are identical. 


What to do Fix the duplicate-name situation and reinvoke the 
linker. 
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Current location, diplaying 1m debug prograa, 5-6 deactivating, C-é 

Cursor, for developaent executive, A-2 Different publics for external error, link program, D-9 


Different values for symbols warning, link progras, D-4 
Directory, typical, 1-4 
D Display address command, debug program. 5-9 


Display ory contents coppand, debug prograa, 5-9 
Data file for GRiDDevetop, 2-2. 2-3 Display of variables, terminating in debug. 5-9 
changing, 2-19 Display variable contents, debug progras, 5-9 
dconB7*Lib™, 3-3 Displaying messages, in debug prograr, 5-7 
Deactivate progras, C-6 Displaying tasks/senaphores in debug, 5-8 
Debug command line commands. 5-9 Do program, C-6 
Debug comsands, using with comeand files, A-3 
assign value, 5-10 DoLarge, 2-2 
clear breakpoint (CODE-C), 5-5 Dump progran, C-7 
display address, 5-9 Duaping eesory contents, debyg progran, 5-10 
display aemory contents, 5-9 Duplicate line command, debug progran, 5-6 
duplicate line (CODE-D), §-6 
examine/change mesory, 5-11 
executive (CODE-E£', 5-6 = 
help (CODE-7), 5-4 
into (CODE-1), 5-6 Edit source frie, 6fiDDevelop command, 2-2 
location display (CODE-L), 5-8 Edit source file aenu, GRiDDevelop, 2-3 
menory dunp, 5-10 Editor, text, See 6RiDWrite 
sessage display (CODE-M), 5-7 ene7*Lib*, 3-2 
sessage display (CODE-M), 5-7 Elapsed time proaran, C-7 
options (CODE-G), 5-7 Enter token, im GRiDDevelop, 2-6 
proceed (CODE-P), S-7 Error eessages, link program, 4-9, D-i 
quit (CODE-Q), 5-7 Error aessages, systea, D-1 
register display (CODE-R?, 5-7 Errors, systea file, C-2 
set breabpoint (CODE-B, 5-5 Exclamation point ¢!), used in Cat prograa, C-5 
tasks/seaaphore disptay (CODE-T), S-€ Evecutatle files, 1-6 
window toggle (CODE-W). 5-B Executive command, debug progras, 5-6 
Debug senu in GRiDDevelop, 2-6 Executive file, ¢-? 
Debug progras, 5-3 Exit from debug prograr. 5-7 
command suseary, 5-2 Exit taken, in GRiDDevelop, 2-7 
compile considerations, 5-2 Extra register initialization warning, link program, D-8 
files, 5-7 Extra start address ignored warning, link progras, D-7 
invoking, 5-2 
link considerations, 5-2 
prompt syabol, 5-3 F 
syntax, 5-3 
Debug records, link progras, 4-8 #BbrnO“Lid™ - fBérn4*Lio®, 3-3 
Debug tokens, Fastload, link control, 4-5, 4-8 
in GRiDDevelop, 2-5 File form, 
using command lines with, 2-5 executing command files from, A-S 
aultiple, 2-6 invoking applications from, 1-5 
Debugger, invoking from GRiDDevelop, 2-5 File kinds, 1-5 
Debugging overiay prograas, B-5 dist of, 1-6 
decimalConstant, debug progras, 5-3 File nanes, 
Decreasing size of segaent warning, link program, D-i0 assumptions 1m GRiDDevelep, 1-5 
Default asenu, GRiDDevelop, 2-1 conventions, 1-3 
Default sodule, in debug. 5-7 restrictions in compilers, 1-5 
Delipeter characters in file names, I-4 language identification in, I-S 
Developoent approaches, alternatives, AI listing with Cat program, C~4 
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Files, 
creating catalog, C-5 
GRiDDevelop data, 2-2, 2-3 
coamand, 1-6, A-3 
coaparing, C 
debug progr. 
duaping, C-7 
executable, 1-6 
GRaDwWrite, 1-& 
include 4 
library, 1-6 
dist, I-é 
log, 2-9 
aap, 1-6 
object, I-6 
organtzing, 1-3 
printing tists and sources in SRiDDevelop. 2-20 
run, 1-6 
systea, C-i 
text, 1-6 

Foras, 
Change source groups, 2-14 
Coapite source files, in GkiDDevelop, 2-13,14 
Link in GRaDDevetop, 2-€,9 
Print list files, 2-21 
Print source files, 2-20 

Fortran 
compiter reference aanual, 3-! 
overlay example, B-5 
run-tiae libraries, 3-3 

Ftn title suffix in GRiDDevelop, 2-12 


GRiDDevelop Commands aenu, 2-17 
with user defined totens, 2-16 
GRi Develop 
compile fora, 2-5 
data file, 2-2, 2-3 
Gata fzle, changing, 2-19 
file nase assuaptions, I-53 
gain menu, 2-1 
message line, 2-16 
predefined tokens, 2-3 
GRiDDevelop tokens, 
Controls, 2-4 
Debug, 2-5 
Enter, 2-6 
Exit, 2-7 
Link, 2-7 
Listings, 2-8 
Lop File, 2-9 
Name, 2-11 
Objects, 2-11 
Prefix, 2-32 
Print to, 2-12 
Source groupNases, 2-1 
Sources, 2-12 
Test, 2-15 
GRiDManager, adding devices froe, C-3 


GRiDWrite, 

files, 1-6 

creating command files with, A-z 

creating source files with, 1-2 

executing command diles from, A-é 

invoking fron GRDDevelop, 2-2 

favoking with GRiDDevelop, 1-3 

editing log files with, 2-9 
Group enlarged warning, link progran, D-5 
Group has no constituent sements warning. link prograe, D-1t 
Group names for source files, 2-17 
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Help command, dedug progr 
hexConstant, debug progras, 5-3 


1/0 ercor, tink progras, D-2 
GAPX @6,08 Utilities User’s Guide, 4-1 
Jliegal fixup error, link progras, D-11 
Iklegat fixup: Incorrect declaration warning, lint program, D-1 
Hlegal overlay construction error, lank prograi 
I}legal use of overtay control error, link program, D-€ 
Taproper fixup warning, lank prograp, D-S 
Improper start address warning, link program, D-6 
Include control statements, examples, 3-5, 3-6 
Include files, 3-4 

Tasting with source files, 2-13 

Paging conventions, 1-5 

organizing, 1-4 

Pascal, 3-5 

PLM, 3-5 
Info command, debug prograa, 5-6 
Input phase error, link program, 0-2 
Input/output routines, 

BRiD-05, 3-2 

Pascal, 3-2 
Insufficient aemory error, link program, D-4 
Intel compiler name restrictions, 1-5 
Invalid syntax error, link prograa, D-é 
Invocation examples, link prograe, 4-2 
Invoking compilers, 3-3 

from command files, A-4 

with GRiDDevelop, 1-3 
Invoking GRiDWrite from GRiDDevelop, 1-3, 2-2 
Invoking the debug prograa, 5-2 

in GRiDDevelop, 2-5 
Invoking the linker progran, 1-2 

in GRiDDevetop, 2-7 
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Kind, see File kinds 
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Language identification in file nanes, 
ge size control, compilers, 3 
LargeSysteaCalis, 2-2 
Lib file kind, 1-4 
Librarian progras, 1-6, 4-1 
Libraries, 3-2 
8087, 3-3 
CompactSysteeCalls, 3-2 
Fortran, 3-3 
LargeSysteaCa)ls, 3-2 
organizing, I-4 
Pascal run-tiee, 3-2 


Library not allowed error, link prograa, 0-8 


linet, debug progras, 5-3 


Link considerations, debug progras, 5-2 


Link controls, 

Assuaeroot, 4-4 

Bind, 4-2, 4-8 

Fastload, §-5, 4-8 

ap, 4-5 

Rage, 4-6 

Overtay, 4-4, 4-6 

Print, 4-7 

Printcontrols, 4-7 

Purge, 4-5, 4-8 

Segment Size, 4-2, 4-0 

supaary of, 4-3 
Link form in GRiDDevelop, 2-8,7 
Link invocation examples, 4-2 
Link @ap files, 1-b, 4-5, 4-9 
Link progras, 4-1 

Qssuseroot control example, B-4 

error aessages, 4-9 

invobing, 1-2, 4-1 

from command files, A-4 
from BRiDDevelop, 2-7 

overlay control exaaple, 8-4 

print file, §-S, 4-7, 4-9 

syntax, 4-1, 2 

warning messages, 4-9 


Link statements, terminating in GRiDDevelop, 


Link tokens, 

in GRiDDevelop, 2-7 

Bultiple, 2-7 
Link warning aessages, D-1 
Link8s error, link prograa, D-5 
Linking overlays, 5-3 
List files, 1-6 

printing, 2-2! 


Listing titles with tne Cat program, C-4 


Listings token in 6RiDDevelop, 2-8 
Load program, C-8 


Location display comeand, debug prograe, S-e 


Log Files, 2-7 
adding entries to, 2-10 


Lst extension, appending by compilers, 2-9 


Lst file kind, 1-6 


Main menu, 6RiDDevetop, 2-1 

Manuals, coapiler reference, 3-1 

fap files, 1-6 

Hap. link control, 4-5, 4-9 

Hdoules, executable, 1-2 

Meaory 
assigning values in debug program, 5-10 
contents, examine/change in debug, 5-11 
displaying contents in debug progran, 5-7 
duap comand, debug program, 5-10 
usage, by a file, Coil 


elop, 2-6 
GRiDDevelop comaands, 2-17 
BRiDDevelop default, 2-1 
GRiDDevelop main, 2-2 
GRiDDevelop Transéer, 2-19 
GRiDDevelop Edit Source File, 2-3 

Message display command, debug program, 5-7 

Message line, displaying in GRiDDevelop, 2-11 

Hetsages, 
link errors, 4-9 
link warnings, 4-9 
warning, D-1 

Nodea, 
device file, C-8 
activating, C-2 

sodule, debug program, 5-3 

Modules, 
Fortran, 3-3 
linking of objects, 1-2 
Pascal, 3-2 

MPL, 4-5, 4-7, 4-9 

MPL file kind, 1-6 


Name assumptions in BRiDDevelop, 1-5 
Name, link control, 4-6 
Wape token in GRiDDevelop, 
exanple of use, 2-11 
Names, adding language identification to, 1-5 
ing conventions, 
for include files, t-5 
for source files, i-S 
Waming files, 1-4 
Waning restrictions in compilers, 1-5 
Wo start address specified warning, link progr. 
Not an object file error, link prograa, D-7 
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Obs 
extension, appending by coapilers, 2-11 
file kind, 1-6 
Obsect files, 1-6 
Size, 4-5 
organizing, 1-4 
Obsect modutes, linking, t-2 
Objects token, in BRiDDevelop, 2-11 
Offset fixup overflow warning, link progran, D-1! 
Options comeand, debug progras, 5-7 
Organizing files, 1-3 
OsOvertay procedure, B-1 
OsPasProcs. inc, 3-5 
OsPasTvpes.Inc, 3-5 
OsPlaProcs.Inc, 3-5 
OsPleTypes.Inc, 3-5 
Overlapping data records warning, link program, D-12 
Overlay control, link prograa, 4-4, 4-4, B-4 
Overlays, Bel 
additional considerations, B-4 
breakpoints, B-4 
Gebugging, B-4 
linking, B-3 
Fortran exaaple of, B-5 
Pascal example of, B-2 
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Pas title suffix in GRiDDevelop, 2-13 
Pascal 

cospiler, reference eanual, 3-3 

include files, 3-5 

overlay example, B-2 

run-time libraries, 3-2 
PL/A 

compiler, reference @anual, 3-1 

title suffix in BRiDDevelop, 2-13 
PLMLits.ane, 3-5 
Possible overlap warning, link program, 0-8 
Predefined tokens in GRiDDevelop, 2-3 
Prefix program, C-8 
Prefix token, in GRiDDevelop, 2-12 
Preprograsmed sofkeys, C-? 
Print file same as input file warning, link pragra: 
Print file same as output file error, link progras 
Print ¢ile, link program, 4-5, 4-7, 4-9 
Print list files form, 2-2! 
Print source files fo 2-20 
Print to toben, in GRiDDevelop, 2-12 
Print, link control, 4-7 
Printcontrols, link control, 4-7 
Printing files in GRiDDevelop, 2-20 
Proceed comaand, debug progras. 5-7 
procNane, debug prograa, 5-3 
Prograa, Pascal declaration, 3-2 
Progr ang softkeys, C-9 
Progeaas subject, C-1 


Prompt syabol, for developsent executive, A-2 
Public records, link progras, 4-8 

Public symbols not sorted warning, link pragrae, 0-12 
Purge, link control, 4-5, 4-8 


Question aarb (7), 
GRiDDevelop command sodifier, 2-17 
used in Cat progrea, C-6 

Dust command, debug progran, 5-7 


Read, Pascal procedures, 3-2 
Register display command, debug progras, 5-7 
Register, debug progras, S-3 
Restrictions on file names in compilers, 1-5 
Root file, 4-4 
Root sodules, B-1 
Run file king, i-& 
Run files, 1-6 
Run-tiee libraries, 
Fortran, 3-3 


Pascal, 3-2 


Same overlay n error, link program, D-9 
Segaent cambination warning, link program, D-z 
Segeent overflow warning, link program, D-« 
Segment size overflow error, link program, D-16 
Segaent size underflow error, link program, D-10 
Segment Size, link control, 4-2, 4-8 
Semaphores, displaying in debug prograa, S-B 
Semicolon (3), 

BRiDBevelop command modifier, 2-37 

Using in copmand files, A-4 
Sequence, developaent, 1-1 
Serial, activating, C-3 
Set breakpoint command, debug program, 5-5 
Size controls, compilers, 3-1, 2 
Size of group exceeds 64K warning, link program, D-1! 
Size, stack segment, 4-8 
Softieys, 

file. €-9 

Bultiple tiles, C-10 

preprograsmed, C-9 
Source files, 

creating, I-2 

compiling, i-2 

egiting from GRiDDevelop, 2-2 

naaing conventions, 1-5 

organizing, 1-4 

printing, 2-20 
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Sources groupNaee token, in GR:DDevelop, 2-13 
Sources token. 

in GRiDDevelop, 2-12 

interaction with Listings token, 2-2 
Specified segwent not found error, lint progras, D- 
SS (see Segaent Size) 
Stack overflow error, lint progras. D-5 
Stack segment, 4-2 
Sudject level, in directories, 1-8 
Suffixes, titles in GR:Dbevelop, 2-17 
Suaaarize program, C-11 
Sunmary of comands, debug progran, 5-2 
Summary of tink controls, 4-3 
Syabols, resolving during overly jinks, & 
Syntax, 

debug progras, 5-2 

systea utilities, C-1 
System errors (ile, C-2 
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Tashs/semaphore d2splay command, debug progras, 5-8 
Tereinating link statenents, in GRiDDevelop, 2-7 
Test aenu, in GRiDDevelap, 2-16 
Test token, in GRiDDevelop, 2-15 
TestName tohen, in GR:DDevelop, 2-15 
Text editor, see BRidWrite 
Text file kind, 1-6 
Text files, I-6 
Thee program, C-11 
Time, elapsed, C-7 
Tithe fevel, in directories, 1-4 
Title suffixes in GRiDDevelap, 2-12 
Titles, 
listing with Cat progras, C-4 
naming, 1-4 
Toggling windows in debug, 5-8 
Tokens 1h GRiDDeveloc, 
Controls, 2-4 
Debug, 2-5 
Enter, 2-6 
Exit, 2-7 
Link, 2-7 
Listings, 2-8 
Log file, 2-10 
Name, 2-11 
Obsects, 2-11 
Prefix, 2-12 
Print to, 2-32 
Source groupNanes, 2-12 
Sources, 2-12 
Test, 2-15 
user-defined, 2-16 
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Too many aain modutes warning, link prograr, D-17 
Too aany overlays error, link pragras, 2-9 
Transfer menu, in GRiDDevelop, 2-19 

Type description too long error, link progr 
Type aisaatch warning, link progeas, O-7 
Typical directory, 1-4 
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Unload progras, C-12 
Unresolved syebols warning, link prograe, D-4 
User-defined tokens, 

in GRiDDevelop, 2-16 

on GRiDDevelop Cooaands aenu, 2-17 


Utilities, iAPX 85,88, 4-1 
Utility programs, C-1 
wildcards in, C-2 
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Variables, 
assigning values in debug program, 5-10 
displaying contents of in debug, 5-7 
varNase, debug program, S-3 


Warning wessages, link prograa, 4-9 
Wildcards, 

in utility prograns. C-2 
Window toggle command, debug program, 5-8 
Mindow, alternate in debug progras, 5-7 
Wort progras, C-12 
Weite, Pascal procedures, 3-2 
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